co2mon.nz currently uses monitors based on Oliver Seiler s open source design which I am personally building. This post describes my exploration of how to achieve production of a CO2 monitor that could enable the growth of co2mon.nz.
Goals
Primarily I want to design a CO2 monitor which allows the majority of the production process to be outsourced. In particular, the PCB should be able to be assembled in an automated fashion (PCBA).
As a secondary goal, I d like to improve the aesthetics of the monitor while retaining the unique feature of displaying clear visual indication of the current ventilation level through coloured lights.
Overall, I ll consider the project successfull if I can achieve a visually attractive CO2 monitor which takes me less than 10 minutes per monitor to assemble/box/ship and whose production cost has the potential to be lower than the current model.
PCB
Schematic
The existing CO2 monitor design provides a solid foundation but relies upon the ESP32 Devkit board, which is intended for evaluation purposes and is not well suited to automated assembly. Replacing this devkit board with the underlying ESP32 module is the major change needed to enable PCBA production, which then also requires moving the supporting electronics from the devkit board directly onto the primary PCB.
The basic ESP32 chipset used in the devkit boards is no longer available as a discrete module suitable for placement directly onto a PCB which means the board will also have to be updated to use a more modern variant of the ESP32 chipset which is in active production such as the ESP32-S3. The ESP32-S3-WROOM1-N4 module is a very close match to the original devkit and will be suitable for this project.
In addition to the change of ESP module, I made the following other changes to the components in use:
Added an additional temperature/humidity sensor (SHT30). The current monitors take temperature/humidity measurements from the SCD40 chipset. These are primarily intended to help in the calculation of CO2 levels and rely on an offset being subtracted to account for the heat generated by the electronic components themselves. I ve found their accuracy to OK, but not perfect. SHT30 is a cheap part, so its addition to hopefully provide improved temperature/humidity measurement is an easy choice.
Swapped to USB-C instead of USB-B for the power connector. USB-C is much more common than USB-B and is also smaller and not as tall off the board which provides more flexibility in the case design.
With major components selected the key task is to draw the schematic diagram describing how they electrically connect to each other, which includes all the supporting electronics (e.g. resistors, capacitors, etc) needed.
I started out trying to use the EasyEDA/OSHWLab ecosystem thinking the tight integration with JLCPCB s assembly services would be a benefit, but the web interface was too clunky and limiting and I quickly got frustrated. KiCad proved to be a much more pleasant and capable tool for the job.
The reference design in the ESP32 datasheet (p28) and USB-C power supply examples from blnlabs were particularly helpful alongside the KiCad documentation and the example of the existing monitor in completing this step (click the image to enlarge).
Layout
The next step is to physically lay out where each component from the schematic will sit on the PCB itself. Obviously this requires first determining the overall size, shape and outline of the board and needs to occur in iteration with the intended design of the overall monitor, including the case, to ensure components like switches and USB sockets line up correctly.
In addition to the requirements around the look and function of the case, the components themselves also have considerations that must be taken into account, including:
For best WiFi reception, the ESP32 antenna should be at the top of the monitor and should not have PCB underneath it, or for a specified distance either side of it.
The SHT30 temperature sensor should be as far from any heat generating components (e.g. the ESP32, BME680 and SCD40 modules) as possible and also considering that any generated heat will rise, as low on the monitor as possible.
The sensors measuring the air (SCD40, BME680 and SHT30) must have good exposure to the air outside the case.
Taking all of these factors into account I ended up with a square PCB containing a cutout in the top right so that the ESP32 antenna can sit within the overall square outline while still meeting its design requirements. The SCD40 and BME680 sit in the top left corner, near the edges for good airflow and far away from the SHT30 temperature sensor in the bottom left corner. The LEDs I placed in a horizontal row across the center of the board, the LCD in the bottom right, a push button on the right-hand side and the USB-C socket in the center at the bottom.
Once the components are placed, the next big task is to route the traces (aka wires) between the components on the board such that all the required electrical connections are made without any unintended connections (aka shorts) being created. This is a fun constraint solving/optimisation challenge and takes on an almost artistic aspect with other PCB designers often having strong opinions on which layout is best. The majority of the traces and routing for this board were able to be placed on the top layer of the PCB, but I also made use of the back layer for a few traces to help avoid conflicts and deal with places where different traces needed to cross each other. It s easy to see how this step would be much more challenging and time consuming on a larger and more complex PCB design.
The final touches were to add some debugging breakouts for the serial and JTAG ports on the ESP32-S3 and a logo and various other helpful text on the silkscreen layer that will be printed on the PCB so it looks nice.
Production
For assembly of the PCB, I went with JLCPCB based out of China. The trickiest part of the process was component selection and ensuring that the parts I had planned in the schematic were available. JLCPCB in conjunction with lcsc.com provides a basic and extended part library. If you use only basic parts you get quicker and cheaper assembly, while using extended parts bumps your order into a longer process with a small fee charged for each component on the board.
Initially I spent a lot of time selecting components (particularly LEDs and switches) that were in the basic library before realising that the ESP32 modules are only available in the extended library! I think the lesson is that unless you re building the most trivial PCB with only passive components you will almost certainly end up in the advanced assembly process anyway, so trying to stay within the basic parts library is not worth the time.
Unfortunately the SCD40 sensor, the most crucial part of the monitor, is not stocked at all by JLCPCB/LCSC! To work around this JLCPCB will maintain a personal component library for you when you ship components to them to for use in future orders. Given the extra logistical time and hassle of having to do this, combined with having a number of SCD40 components already on hand I decided to have the boards assembled without this component populated for the initial prototype run. This also had the benefit of lowering the risk if something went wrong as the cost of the SCD40 is greater than the cost of the PCB and all the other components combined!
I found the kicad-jlcpcb-tools plugin for KiCad invaluable for keeping track of what part from lcsc.com I was planning to use for each component and generating the necessary output files for JLCPCB. The plugin allows you to store these mappings in your actual schematic which is very handy. The search interface it provides is fairly clunky and I found it was often easier to search for the part I needed on lcsc.com and then just copy the part number across into the plugin s search box rather than trying to search by name or component type.
The LCD screen is the remaining component which is not easily assembled onto the PCB directly, but as you ll see next, this actually turned out to be OK as integrating the screen directly into the case makes the final assembly process smoother.
The final surprise in the assembly process was the concept of edge rails, additional PCB material that is needed on either side of the board to help with feeding it through the assembly machine in the correct position. These can be added automatically by JLCPCB and have to be snapped off after the completed boards are received. I hadn t heard about these before and I was a little worried that they d interfere or get in the way of either the antenna cut-out at the top of the board, or the switch on the right hand side as it overhangs the edge so it can sit flush with the case.
In the end there was no issue with the edge rails. The switch was placed hanging over them without issue and snapping them off once the boards arrived was a trivial 30s job using a vice to hold the edge rail and then gently tipping the board over until it snapped off - the interface between the board and the rails while solid looking has obviously been scored or perforated in some way during the production process so the edge breaks cleanly and smoothly. Magic!
The process was amazingly quick with the completed PCBs (picture above) arriving within 7 days of the order being placed and looking amazing.
Case
Design
I mocked up a very simple prototype of the case in FreeCAD during the PCB design process to help position and align the placement of the screen, switch and USB socket on the PCB as all three of these components interface directly with the edges of the case. Initially this design was similar to the current monitor design where the PCB (with lights and screen attached) sits in the bottom of the case, which has walls containing grilles for airflow and then a separate transparent perspex is screwed onto the top to complete the enclosure.
As part of the aesthetic improvements for the new monitor I wanted to move away from a transparent front panel to something opaque but still translucent enough to allow the colour of the lights to show through. Without a transparent front panel the LCD also needs to be mounted directly into the case itself.
The first few prototype iterations followed the design of the original CO2 monitor with a flat front panel that attaches to the rest of the case containing the PCB, but the new requirement to also attach the LCD to the front panel proved to make this unworkable. To stay in place the LCD has to be pushed onto mounting poles containing a catch mechanism which requires a moderate amount of force and applying that force to the LCD board when it is already connected to the PCB is essentially impossible.
As a result I ended up completely flipping the design such that the front panel is a single piece of plastic that also encompasses the walls of the case and contains appropriate mounting stakes for both the screen and the main PCB.
Getting to this design hugely simplified the assembly process. Starting with an empty case lying face down on a bench, the LCD screen is pushed onto the mounting poles and sits flush with the cover of the case - easily achieved without the main PCB yet in place.
Next, the main PCB is gently lowered into the case facing downwards and sits on the mounting pole in each corner with the pins for the LCD just protruding through the appropriate holes in the PCB ready to be quickly soldered into place (this took significant iteration and tuning of dimensions/positioning to achieve!).
Finally, a back panel can be attached which holds the PCB in place and uses cantilever snap joints to click on to the rest of the case.
Overall the design is a huge improvement over the previous case which required screws and spacers to position the PCB and cover relative to the rest of the case, with the spacers and screws being particularly fiddly to work with.
The major concern I had with the new design was that the mount to attach the monitor to the wall has moved from being attached to the main case and components directly to needing to be on the removable back panel - if the clips holding this panel to the case fail the core part of the monitor will fall off the wall which would not be good. To guard against this I ve doubled the size and number of clips at the top of the case (which bears the weight) and the result seems very robust in my testing. To completely assemble a monitor, including the soldering step takes me about 2-3 minutes individually, and would be even quicker if working in batches.
Production
Given the number of design/testing iterations required to fine tune the case I chose not to outsource case production for now and used my 3D printer to produce them. I ve successfully used JLCPCB s 3D printing service for the previous case design, so I m confident that getting sufficient cases printed from JLCPCB or another supplier will not be an issue now that the design is finalised.
I tried a variety of filament colours, but settled on a transparent filament which once combined in the necessary layers to form the case is not actually transparent like perspex is, but provides a nice translucent medium which achieves the goal of having the light colour visible without exposing all of the circuit board detail. There s room for future improvement in the positioning of the LEDs on the circuit board to provide a more even distribution of light across the case but overall I really like the way the completed monitor ends up looking.
Evaluation
Building this monitor has been a really fun project, both in seeing something progress from an idea, to plans on a screen to a nice physical thing on my wall, but also in learning and developing a bunch of new skills in PCB design, assembly and 3D design.
The goal of having a CO2 monitor which I can outsource the vast majority of production of is as close to being met as I think is possible without undertaking the final proof of placing a large order. I ve satisfied myself that each step is feasible and that the final assembly process is quick, easy and well below the level of effort and time it was taking me to produce the original monitors.
Cost wise it s also a huge win, primarily in terms of the time taken, but also in the raw components - currently the five prototypes I ordered and built are on par with the component cost of the original CO2 monitor, but this will drop further with larger orders due to price breaks and amortisation of the setup and shipping expenses across more monitors.
This project has also given me a much better appreciation for how much I m only just scratching the surface of the potential complexities and challenges in producing a hardware product of this type.
I m reasonably confident I could successfully produce a few hundred and maybe even a few thousand monitors using this approach, but it s also clear that getting beyond that point is and would be a whole further level of effort and learning.
Hardware is hard work. That s not news to anyone, including me, but there is something to be said for experiencing the process first hand to make the reality of what s required real.
The PCB and case designs are both shared and can be found at https://github.com/co2monnz/co2monitor-pcb and https://github.com/co2monnz/cad, feedback and suggestions welcome!
Furious Heaven is the middle book of a trilogy and a direct sequel
to Unconquerable Sun. Don't start here.
I also had some trouble remembering what happened in the previous book
(grumble recaps mutter), and there are a lot of threads, so I would try to
minimize the time between books unless you have a good memory for plot
details.
This is installment two of gender-swapped Alexander the Great in space.
When we last left Sun and her Companions, Elliott had established the
major players in this interstellar balance of power and set off some
opening skirmishes, but the real battles were yet to come. Sun was trying
to build her reputation and power base while carefully staying on the good
side of Queen-Marshal Eirene, her mother and the person credited with
saving the Republic of Chaonia from foreign dominance. The best parts of
the first book weren't Sun herself but wily Persephone, one of her
Companions, whose viewpoint chapters told a more human-level story of
finding her place inside a close-knit pre-existing friendship group.
Furious Heaven turns that all on its head. The details are
spoilers (insofar as a plot closely tracking the life of Alexander the
Great can contain spoilers), but the best parts of the second book are the
chapters about or around Sun.
What I find most impressive about this series so far is Elliott's ability
to write Sun as charismatic in a way that I can believe as a reader. That
was hit and miss at the start of the series, got better towards the end of
Unconquerable Sun, and was wholly effective here. From me, that's
high but perhaps unreliable praise; I typically find people others
describe as charismatic to be some combination of disturbing,
uncomfortable, dangerous, or obviously fake. This is a rare case of
intentionally-written fictional charisma that worked for me.
Elliott does not do this by toning down Sun's ambition. Sun, even more
than her mother, is explicitly trying to gather power and bend the
universe (and the people in it) to her will. She treats people as
resources, even those she's the closest to, and she's ruthless in pursuit
of her goals. But she's also honorable, straightforward, and generous to
the people around her. She doesn't lie about her intentions; she follows
a strict moral code of her own, keeps her friends' secrets, listens
sincerely to their advice, and has the sort of battlefield charisma where
she refuses to ask anyone else to take risks she personally wouldn't take.
And her use of symbolism and spectacle isn't just superficial; she finds
the points of connection between the symbols and her values so that she
can sincerely believe in what she's doing.
I am fascinated by how Elliott shapes the story around her charisma.
Writing an Alexander analogue is difficult; one has to write a tactical
genius with the kind of magnetic attraction that enabled him to lead an
army across the known world, and make this believable to the reader.
Elliott gives Sun good propaganda outlets and makes her astonishingly
decisive (and, of course, uses the power of the author to ensure those
decisions are good ones), but she also shows how Sun is constantly
absorbing information and updating her assumptions to lay the groundwork
for those split-second decisions. Sun uses her Companions like a
foundation and a recovery platform, leaning on them and relying on them to
gather her breath and flesh out her understanding, and then leaping from
them towards her next goal. Elliott writes her as thinking just a tiny
bit faster than the reader, taking actions I was starting to expect but
slightly before I had put together my expectation. It's a subtle but
difficult tightrope to walk as the writer, and it was incredibly effective
for me.
The downside of Furious Heaven is that, despite kicking the action
into a much higher gear, this book sprawls. There are five viewpoint
characters (Persephone and the Phene Empire character Apama from the first
book, plus two new ones), as well as a few interlude chapters from yet
more viewpoints. Apama's thread, which felt like a minor subplot of the
first book, starts paying off in this book by showing the internal
political details of Sun's enemy. That already means the reader has to
track two largely separate and important stories. Add on a Persephone
side plot about her family and a new plot thread about other political
factions and it's a bit too much. Elliott does a good job avoiding reader
confusion, but she still loses narrative momentum and reader interest due
to the sheer scope.
Persephone's thread in particular was a bit disappointing after being the
highlight of the previous book. She spends a lot of her emotional energy
on tedious and annoying sniping at Jade, which accomplishes little other
than making them both seem immature and out of step with the significance
of what's going on elsewhere.
This is also a middle book of a trilogy, and it shows. It provides a
satisfying increase in intensity and gets the true plot of the trilogy
well underway, but nothing is resolved and a lot of new questions and plot
threads are raised. I had similar problems with Cold Fire, the middle book of the other Kate Elliott trilogy I've
read, and this book is 200 pages longer. Elliott loves world-building and
huge, complex plots; I have a soft spot for them too, but they mean the
story is full of stuff, and it's hard to maintain the same level of reader
interest across all the complications and viewpoints.
That said, I truly love the world-building. Elliott gives her world
historical layers, with multiple levels of lost technology, lost history,
and fallen empires, and backs it up with enough set pieces and fragments
of invented history that I was enthralled. There are at least five major
factions with different histories, cultures, and approaches to technology,
and although they all share a history, they interpret that history in
fascinatingly different ways. This world feels both lived in and full of
important mysteries.
Elliott also has a knack for backing the ambitions of her characters with
symbolism that defines the shape of that ambition. The title comes from a
(translated) verse of an in-universe song called the Hymn of Leaving,
which is sung at funerals and is about the flight on generation ships from
the now-lost Celestial Empire, the founding myth of this region of space:
Crossing the ocean of stars we leave our home behind us.
We are the spears cast at the furious heaven
And we will burn one by one into ashes
As with the last sparks we vanish.
This memory we carry to our own death which awaits us
And from which none of us will return.
Do not forget. Goodbye forever.
This is not great poetry, but it explains so much about the psychology of
the characters. Sun repeatedly describes herself and her allies as spears
cast at the furious heaven. Her mother's life mission was to make Chaonia
a respected independent power. Hers is much more than that, reaching back
into myth for stories of impossible leaps into space, burning brightly
against the hostile power of the universe itself.
A question about a series like this is why one should want to read about a
gender-swapped Alexander the Great in space, rather than just reading
about Alexander himself. One good (and sufficient) answer is that both
the gender swap and the space parts are inherently interesting. But the
other place that Elliott uses the science fiction background is to give
Sun motives beyond sheer personal ambition.
At a critical moment in the story, just like Alexander, Sun takes a detour
to consult an Oracle. Because this is a science fiction novel, it's a
great SF set piece involving a mysterious AI. But also because this is a
science fiction story, Sun doesn't only ask about her personal ambitions.
I won't spoil the exact questions; I think the moment is better not
knowing what she'll ask. But they're science fiction questions, reader
questions, the kinds of things Elliott has been building curiosity about
for a book and a half by the time we reach that scene. Half the fun of
reading a good epic space opera is learning the mysteries hidden in the
layers of world-building. Aligning the goals of the protagonist with the
goals of the reader is a simple storytelling trick, but oh, so effective.
Structurally, this is not that great of a book. There's a lot of build-up
and only some payoff, and there were several bits I found grating. But I
am thoroughly invested in this universe now. The third book can't come
soon enough.
Followed by Lady Chaos, which is still being written at the time of
this review.
Rating: 7 out of 10
I've moved to having containers be first-class citizens on my home network, so
any local machine (laptop, phone,tablet) can communicate directly with them all,
but they're not (by default) exposed to the wider Internet. Here's why, and how.
After I moved containers from docker to Podman and
systemd, it became much more convenient to run web apps on
my home server, but the default approach to networking
(each container gets an address on a private network between the host server
and containers) meant tedious work (maintaining and reconfiguring a HTTP
reverse proxy) to make them reachable by other devices. A more attractive
arrangement would be if each container received an IP from the range used by
my home LAN, and were automatically addressable from any device on it.
To make the containers first-class citizens on my home LAN, first I needed to
configure a Linux network bridge and attach the host machine's interface to it
(I've done that many times before);
then define a new Podman network, of type "bridge". podman-network-create
(1)
serves as reference, but the blog post Exposing Podman containers fully on the
network
is an easier read (skip past the macvlan bit).
I've opted to choose IP addresses for each container by hand. The Podman
network is narrowly defined to a range of IPs that are within the subnet that
my ISP-provided router uses, but outside the range of IPs that it allocates.
When I start up a container by hand for the first time, I choose a free IP from
the sub-range by hand and add a line to /etc/avahi/hosts on the parent
machine, e.g.
192.168.1.33 octoprint.local
I then start the container specifying that address, e.g.
I can now access that container from any device in my house (laptop, phone,
tablet...) via octoprint.local.
What's next
Although it's not a huge burden, it would be nice to not need to statically
define the addresses in /etc/avahi/hosts (perhaps via "IPAM"). I've also been
looking at
WireGuard
(which should be the subject of a future blog post) and combining this with
that would be worthwhile.
Just a few days back we came to know about the horrific Train Crash that happened in Odisha (Orissa). There are some things that are known and somethings that can be inferred by observance. Sadly, it seems the incident is going to be covered up . Some of the facts that have not been contested in the public domain are that there were three lines. One loop line on which the Goods Train was standing and there was an up and a down line. So three lines were there. Apparently, the signalling system and the inter-locking system had issues as highlighted by an official about a month back. That letter, thankfully is in the public domain and I have downloaded it as well. It s a letter that goes to 4 pages. The RW is incensed that the letter got leaked and is in public domain. They are blaming everyone and espousing conspiracy theories rather than taking the minister to task. Incidentally, the Minister has three ministries that he currently holds. Ministry of Communication, Ministry of Electronics and Information Technology (MEIT), and Railways Ministry. Each Ministry in itself is important and has revenues of more than 6 lakh crore rupees. How he is able to do justice to all the three ministries is beyond me
The other thing is funds both for safety and relaying of tracks has been either not sanctioned or unutilized. In fact, CAG and the Railway Brass had shared how derailments have increased and unfulfilled vacancies but they were given no importance In fact, not talking about safety in the recently held Chintan Shivir (brainstorming session) tells you how much the Govt. is serious about safety. In fact, most of the programme was on high speed rail which is a white elephant. I have shared a whitepaper done by RW in the U.S. that tells how high-speed rail doesn t make economic sense. And that is an economy that is 20 times + the Indian Economy. Even the Chinese are stopping with HSR as it doesn t make economic sense.
Incidentally, Air Fares again went up 200% yesterday. Somebody shared in the region of 20k + for an Air ticket from their place to Bangalore
Coming back to the story itself. the Goods Train was on the loopline. Some say it was a little bit on the outer, some say otherwise, but it is established that it was on the loopline. This is standard behavior on and around Railway Stations around the world. Whether it was in the Inner or Outer doesn t make much of a difference with what happened next. The first train that collided with the goods train was the 12864 (SMVB-HWH) Yashwantpur Howrah Express and got derailed on to the next track where from the opposite direction 12841 (Shalimar- Bangalore) Coramandel Express was coming. Now they have said that around 300 people have died and that seems to be part of the cover-up. Both the trains are long trains, having between 23 odd coaches each. Even if you have reserved tickets you have 80 odd people in a coach and usually in most of these trains, it is at least double of that. Lot of money goes to TC and then above (Corruption). The Railway fares have gone up enormously but that s a question for perhaps another time . So at the very least, we could be looking at more than 1000 people having died. The numbers are being under-reported so that nobody has to take responsibility. The Railways itself has told that it is unable to identify 80% of the people who have died. This means that 80% were unreserved ticket holders or a majority of them. There have been disturbing images as how bodies have been flung over on tractors and whatnot to be either buried or cremated without a thought. We are in peak summer season so bodies will start to rot within 24-48 hours No arrangements made to cool the bodies and take some information and identifying marks or whatever. The whole thing being done in a very callous manner, not giving dignity to even those who have died for no fault of their own. The dissent note also tells that a cover-up is also in the picture. Apparently, India doesn t have nor does it feel to have a need for something like the NTSB that the U.S. used when it hauled both the plane manufacturer (Boeing) and the FAA when the 737 Max went down due to improper data collection and sharing of data with pilots. And with no accountability being fixed to Minister or any of the senior staff, a small junior staff person may be fired. Perhaps the same official that actually told them about the signal failures almost 3 months back
There were and are also some reports that some jugaadu /temporary fixes were applied to signalling and inter-locking just before this incident happened. I do not know nor confirm one way or the other if the above happened. I can however point out that if such a thing happened, then usually a traffic block is announced and all traffic on those lines are stopped. This has been the thing I know for decades. Traveling between Mumbai and Pune multiple times over the years am aware about traffic block. If some repair work was going on and it wasn t able to complete the work within the time-frame then that may well have contributed to the accident. There is also a bit muddying of the waters where it is being said that one of the trains was 4 hours late, which one is conflicting stories.
On top of the whole thing, they have put the case to be investigated by CBI and hinting at sabotage. They also tried to paint a religious structure as mosque, later turned out to be a temple. The RW says done by Muslims as it was Friday not taking into account as shared before that most Railway maintenance works are usually done between Friday Monday. This is a practice followed not just in India but world over.
There has been also move over a decade to remove wooden sleepers and have concrete sleepers. Unlike the wooden ones they do not expand and contract as much and their life is much more longer than the wooden ones. Funds had been marked (although lower than last few years) but not yet spent. As we know in case of any accident, it is when all the holes in cheese line up it happens. Fukushima is a great example of that, no sea wall even though Japan is no stranger to Tsunamis. External power at the same level as the plant. (10 meters above sea-level), no training for cascading failures scenarios which is what happened. The Days mini-series shares some but not all the faults that happened at Fukushima and the Govt. response to it. There is a difference though, the Japanese Prime Minister resigned on moral grounds. Here, nor the PM, nor the Minister would be resigning on moral grounds or otherwise :(. Zero accountability and that was partly a natural disaster, here it s man-made. In fact, both the Minister and the Prime Minister arrived with their entourages, did a PR blitzkrieg showing how concerned they are. Within 50 hours, the lines were cleared. The part-time Railway Minister shared that he knows the root cause and then few hours later has given the case to CBI. All are saying, wait for the inquiry report. To date, none of the accidents even in this Govt. has produced an investigation report. And even if it did, I am sure it will whitewash as it did in case of Adani as I had shared before in the previous blog post. Incidentally, it is reported that Adani paid off some of its debt, but when questioned as to where they got the money, complete silence on that part :(. As can be seen cover-up after cover-up
FWIW, the Coramandel Express is known as the Migrant train so has a huge number of passengers, the other one which was collided with is known as sick train as huge number of cancer patients use it to travel to Chennai and come back
Demonetization 2.0
Few days back, India announced demonetization 2.0. Surprised, don t be. Apparently, INR 2k/- is being used for corruption and Mr. Modi is unhappy about it. He actually didn t like the INR 2k/- note but was told that it was needed, who told him we are unaware to date. At that time the RBI Governor was Mr. Urjit Patel who didn t say about INR 2k/- he had said that INR 1k/- note redesigned would come in the market. That has yet to happen. What has happened is that just like INR 500/- and INR 1k/- note is concerned, RBI will no longer honor the INR 2k/- note. Obviously, this has made our neighbors angry, namely Nepal, Sri Lanka, Bhutan etc. who do some trading with us. 2 Deccan heraldcolumns share the limelight on it. Apparently, India wants to be the world s currency reserve but doesn t want to play by the rules for everyone else. It was pointed out that both the U.S. and Singapore had retired their currencies but they will honor that promise even today. The Singapore example being a bit closer (as it s in Asia) is perhaps a bit more relevant than the U.S. one. Singapore retired the SGD $10,000 as of 2014 but even in 2022, it remains as legal tender. They also retired the SGD $1,000 in 2020 but still remains legal tender.
So let s have a fictitious example to illustrate what is meant by what Singapore has done. Let s say I go to Singapore, rent a flat, and find a $1000 note in that house somewhere. Both practically and theoretically, I could go down to any of the banks, get the amount transferred to my wallet, bank account etc. and nobody will question. Because they have promised the same. Interestingly, the Singapore Dollar has been pretty resilient against the USD for quite a number of years vis-a-vis other Asian currencies.
Most of the INR 2k/- notes were also found and exchanged in Gujarat in just a few days (The PM and HM s state.). I am sure you are looking into the mental gymnastics that the RW indulge in :(. What is sadder that most of the people who try to defend can t make sense one way or the other and start to name-call and get personal as they have nothing else
Disability questions dropped in NHFS-6
Just came to know today that in the upcoming National Family Health Survey-6 disability questions are being dropped. Why is this important. To put it simply, if you don t have numbers, you won t and can t make policies for them. India is one of the worst countries to live if you are disabled. The easiest way to share to draw attention is most Railway platforms are not at level with people. Just as Mick Lynch shares in the UK, the same is pretty much true for India too. Meanwhile in Europe, they do make an effort to be level so even disabled people have some dignity. If your public transport is sorted, then people would want much more and you will be obligated to provide for them as they are citizens. Here, we have had many reports of women being sexually molested when being transferred from platform to coach irrespective of their age or whatnot The main takeaway is if you do not have their voice, you won t make policies for them. They won t go away but you will make life hell for them. One thing to keep in mind that most people assume that most people are disabled from birth. This may or may not be true. For e.g. in the above triple Railways accidents, there are bound to be disabled people or newly disabled people who were healthy before the accident. The most common accident is road accidents, some involving pedestrians and vehicles or both, the easiest is Ministry of Road Transport data that says 4,00,000 people sustained injuries in 2021 alone in road mishaps. And this is in a country where even accidents are highly under-reported, for more than one reason. The biggest reason especially in 2 and 4 wheeler is the increased premium they would have to pay if in an accident, so they usually compromise with the other and pay off the Traffic Inspector.
Sadly, I haven t read a new book, although there are a few books I m looking forward to have. People living in India and neighbors please be careful as more heat waves are expected. Till later.
Welcome to the May 2023 report from the Reproducible Builds project
In our reports, we outline the most important things that we have been up to over the past month. As always, if you are interested in contributing to the project, please visit our Contribute page on our website.
When using open-source NPM packages, most developers download prebuilt packages on npmjs.com instead of building those packages from available source, and implicitly trust the downloaded packages. However, it is unknown whether the blindly trusted prebuilt NPM packages are reproducible (i.e., whether there is always a verifiable path from source code to any published NPM package). [ ] We downloaded versions/releases of 226 most popularly used NPM packages and then built each version with the available source on GitHub. Next, we applied a differencing tool to compare the versions we built against versions downloaded from NPM, and further inspected any reported difference.
The paper reports that among the 3,390 versions of the 226 packages, only 2,087 versions are reproducible, and furthermore that multiple factors contribute to the non-reproducibility including flexible versioning information in package.json file and the divergent behaviors between distinct versions of tools used in the build process. The paper concludes with insights for future verifiable build procedures.
Unfortunately, a PDF is not available publically yet, but a Digital Object Identifier (DOI) is available on the paper s IEEE page.
Elsewhere in academia, Betul Gokkaya, Leonardo Aniello and Basel Halak of the School of Electronics and Computer Science at the University of Southampton published a new paper containing a broad overview of attacks and comprehensive risk assessment for software supply chain security.
Their paper, titled Software supply chain: review of attacks, risk assessment strategies and security controls, analyses the most common software supply-chain attacks by providing the latest trend of analyzed attack, and identifies the security risks for open-source and third-party software supply chains. Furthermore, their study introduces unique security controls to mitigate analyzed cyber-attacks and risks by linking them with real-life security incidence and attacks . (arXiv.org, PDF)
NixOS is now tracking two new reports at reproducible.nixos.org. Aside from the collection of build-time dependencies of the minimal and Gnome installation ISOs, this page now also contains reports that are restricted to the artifacts that make it into the image. The minimal ISO is currently reproducible except for Python 3.10, which hopefully will be resolved with the coming update to Python version 3.11.
On our rb-general mailing list this month:
David A. Wheeler started a thread noting that the OSSGadget project s oss-reproducible tool was measuring something related to but not the same as reproducible builds. Initially they had adopted the term semantically reproducible build term for what it measured, which they defined as being if its build results can be either recreated exactly (a bit for bit reproducible build), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases. This generated a significant number of replies, and several were concerned that people might confuse what they were measuring with reproducible builds . After discussion, the OSSGadget developers decided to switch to the term semantically equivalent for what they measured in order to reduce the risk of confusion.
Vagrant Cascadian (vagrantc) posted an update about GCC, binutils, and Debian s build-essential set with some progress, some hope, and I daresay, some fears .
Lastly, kpcyrd asked a question about building a reproducible Linux kernel package for Arch Linux (answered by Arnout Engelen). In the same, thread David A. Wheeler pointed out that the Linux Kernel documentation has a chapter about Reproducible kernel builds now as well.
In Debian this month, nine reviews of Debian packages were added, 20 were updated and 6 were removed this month, all adding to our knowledge about identified issues. In addition, Vagrant Cascadian added a link to the source code causing various ecbuild issues. []
The F-Droid project updated its Inclusion How-To with a new section explaining why it considers reproducible builds to be best practice and hopes developers will support the team s efforts to make as many (new) apps reproducible as it reasonably can.
In diffoscope development this month, version 242 was uploaded to Debian unstable by Chris Lamb who also made the following changes:
If binwalk is not available, ensure the user knows they may be missing more info. []
Factor out generating a human-readable comment when missing a Python module. []
In addition, Mattia Rizzolo documented how to (re)-produce a binary blob in the code [] and Vagrant Cascadian updated the version of diffoscope in GNU Guix to 242 [].
reprotest is our tool for building the same source code twice in different environments and then checking the binaries produced by each build for any differences. This month, Holger Levsen uploaded versions 0.7.24 and 0.7.25 to Debian unstable which added support for Tox versions 3 and 4 with help from Vagrant Cascadian [][][]
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
In addition, Jason A. Donenfeld filed a bug (now fixed in the latest alpha version) in the Android issue tracker to report that generateLocaleConfig in Android Gradle Plugin version 8.1.0 generates XML files using non-deterministic ordering, breaking reproducible builds. []
Testing framework
The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In May, a number of changes were made by Holger Levsen:
Update the kernel configuration of arm64 nodes only put required modules in the initrd to save space in the /boot partition. []
A huge number of changes to a new tool to document/track Jenkins node maintenance, including adding --fetch, --help, --no-future and --verbose options [][][][] as well as adding a suite of new actions, such as apt-upgrade, command, deploy-git, rmstamp, etc. [][][][] in addition a significant amount of refactoring [][][][].
Issue warnings if apt has updates to install. []
Allow Jenkins to run apt get update in maintenance job. []
Installed bind9-dnsutils on some Ubuntu 18.04 nodes. [][]
Fixed the Jenkins shell monitor to correctly deal with little-used directories. []
Updated the node health check to warn when apt upgrades are available. []
Performed some node maintenance. []
In addition, Vagrant Cascadian added the nocheck, nopgo and nolto when building gcc-* and binutils packages [] as well as performed some node maintenance [][]. In addition, Roland Clobus updated the openQA configuration to specify longer timeouts and access to the developer mode [] and updated the URL used for reproducible Debian Live images [].
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
FTP master
This month I accepted 157 and rejected 22 packages. The overall number of packages that got accepted was 160.
Debian LTS
This was my hundred-seventh month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.
This month my all in all workload has been 14h.
During that time I uploaded:
[DLA 3430-1] cups-filters security update for one CVE
[DSA 5407-1] cups-filters security update for one CVE
[unstable] upload of cups-filters to fix CVE-2023-24805
[#1036548] unblock bug to fix CVE-2023-24805 in bookworm
[unstable] upload of sniproxy to fix CVE-2023-25076
[DSA 5413-1] sniproxy security update in Bullseye for one CVE
[cups] working to fix CVE-2023-32324 in unstable, Bookworm, Bullseye, Buster
The CVEs for cups-filters and cups have been embargoed ones, so the work for cups was done in May but the uploads happen in June.
I also did some work on security-master to inject missing dependencies for hugo and gitlab-workhose.
Last but not least I did some days on frontdesk duties.
Debian ELTS
This month was the fifty eighth ELTS month.
[ELA-852-1] cups-filters security update in Jessie and Stretch for one CVE
[ELA-856-1] freetype security update in Jessie and Stretch for two CVEs
[ELA-857-1] libtasn1-6 security update in Jessie and Stretch for one CVE
[cups] working to fix CVE-2023-32324 in Jessie and Stretch
The CVEs for cups-filters and cups have been embargoed ones, so the work for cups was done in May but the uploads happen in June.
Last but not least I did some days on frontdesk duties.
Debian Astro
This month I uploaded some packages to fix RC bugs, that were
detected by one of many QA tools:
I even did an upload of a new package force-ip-protocol. I finally had enough of people using IPv6 for their hosts but are unable to configure it. Now I can force firefox, or whatever software, to only use IPv4. One nuisance settled.
I m calling time on DNSSEC. Last week, prompted by a change in my DNS hosting setup, I began removing it from the few personal zones I had signed. Then this Monday the .nz ccTLD experienced a multi-day availability incident triggered by the annual DNSSEC key rotation process. This incident broke several of my unsigned zones, which led me to say very unkind things about DNSSEC on Mastodon and now I feel compelled to more completely explain my thinking:
For almost all domains and use-cases, the costs and risks of deploying DNSSEC outweigh the benefits it provides. Don t bother signing your zones.
The .nz incident, while topical, is not the motivation or the trigger for this conclusion. Had it been a novel incident, it would still have been annoying, but novel incidents are how we learn so I have a small tolerance for them. The problem with DNSSEC is precisely that this incident was not novel, just the latest in a long and growing list.
It s a clear pattern. DNSSEC is complex and risky to deploy. Choosing to sign your zone will almost inevitably mean that you will experience lower availability for your domain over time than if you leave it unsigned. Even if you have a team of DNS experts maintaining your zone and DNS infrastructure, the risk of routine operational tasks triggering a loss of availability (unrelated to any attempted attacks that DNSSEC may thwart) is very high - almost guaranteed to occur. Worse, because of the nature of DNS and DNSSEC these incidents will tend to be prolonged and out of your control to remediate in a timely fashion.
The only benefit you get in return for accepting this almost certain reduction in availability is trust in the integrity of the DNS data a subset of your users (those who validate DNSSEC) receive. Trusted DNS data that is then used to communicate across an untrusted network layer. An untrusted network layer which you are almost certainly protecting with TLS which provides a more comprehensive and trustworthy set of security guarantees than DNSSEC is capable of, and provides those guarantees to all your users regardless of whether they are validating DNSSEC or not.
In summary, in our modern world where TLS is ubiquitous, DNSSEC provides only a thin layer of redundant protection on top of the comprehensive guarantees provided by TLS, but adds significant operational complexity, cost and a high likelihood of lowered availability.
In an ideal world, where the deployment cost of DNSSEC and the risk of DNSSEC-induced outages were both low, it would absolutely be desirable to have that redundancy in our layers of protection. In the real world, given the DNSSEC protocol we have today, the choice to avoid its complexity and rely on TLS alone is not at all painful or risky to make as the operator of an online service. In fact, it s the prudent choice that will result in better overall security outcomes for your users.
Ignore DNSSEC and invest the time and resources you would have spent deploying it improving your TLS key and certificate management.
Ironically, the one use-case where I think a valid counter-argument for this position can be made is TLDs (including ccTLDs such as .nz). Despite its many failings, DNSSEC is an Internet Standard, and as infrastructure providers, TLDs have an obligation to enable its use. Unfortunately this means that everyone has to bear the costs, complexities and availability risks that DNSSEC burdens these operators with. We can t avoid that fact, but we can avoid creating further costs, complexities and risks by choosing not to deploy DNSSEC on the rest of our non-TLD zones.
But DNSSEC will save us from the evil CA ecosystem!
Historically, the strongest motivation for DNSSEC has not been the direct security benefits themselves (which as explained above are minimal compared to what TLS provides), but in the new capabilities and use-cases that could be enabled if DNS were able to provide integrity and trusted data to applications.
Specifically, the promise of DNS-based Authentication of Named Entities (DANE) is that with DNSSEC we can be free of the X.509 certificate authority ecosystem and along with it the expensive certificate issuance racket and dubious trust properties that have long been its most distinguishing features.
Ten years ago this was an extremely compelling proposition with significant potential to improve the Internet. That potential has gone unfulfilled.
Instead of maturing as deployments progressed and associated operational experience was gained, DNSSEC has been beset by the discovery of issue after issue. Each of these has necessitated further changes and additions to the protocol, increasing complexity and deployment cost. For many zones, including significant zones like google.com (where I led the attempt to evaluate and deploy DNSSEC in the mid 2010s), it is simply infeasible to deploy the protocol at all, let alone in a reliable and dependable manner.
While DNSSEC maturation and deployment has been languishing, the TLS ecosystem has been steadily and impressively improving. Thanks to the efforts of many individuals and companies, although still founded on the use of a set of root certificate authorities, the TLS and CA ecosystem today features transparency, validation and multi-party accountability that comprehensively build trust in the ability to depend and rely upon the security guarantees that TLS provides. When you use TLS today, you benefit from:
Free/cheap issuance from a number of different certificate authorities.
Regular, automated issuance/renewal via the ACME protocol.
Visibility into who has issued certificates for your domain and when through Certificate Transparency logs.
Confidence that certificates issued without certificate transparency (and therefore lacking an SCT) will not be accepted by the leading modern browsers.
The use of modern cryptographic protocols as a baseline, with a plausible and compelling story for how these can be steadily and promptly updated over time.
DNSSEC with DANE can match the TLS ecosystem on the first benefit (up front price) and perhaps makes the second benefit moot, but has no ability to match any of the other transparency and accountability measures that today s TLS ecosystem offers. If your ZSK is stolen, or a parent zone is compromised or coerced, validly signed TLSA records for a forged certificate can be produced and spoofed to users under attack with minimal chances of detection.
Finally, in terms of overall trust in the roots of the system, the CA/Browser forum requirements continue to improve the accountability and transparency of TLS certificate authorities, significantly reducing the ability for any single actor (say a nefarious government) to subvert the system. The DNS root has a well established transparent multi-party system for establishing trust in the DNSSEC root itself, but at the TLD level, almost intentionally thanks to the hierarchical nature of DNS, DNSSEC has multiple single points of control (or coercion) which exist outside of any formal system of transparency or accountability.
We ve moved from DANE being a potential improvement in security over TLS when it was first proposed, to being a definite regression from what TLS provides today.
That s not to say that TLS is perfect, but given where we re at, we ll get a better security return from further investment and improvements in the TLS ecosystem than we will from trying to fix DNSSEC.
But TLS is not ubiquitous for non-HTTP applications
The arguments above are most compelling when applied to the web-based HTTP-oriented ecosystem which has driven most of the TLS improvements we ve seen to date. Non-HTTP protocols are lagging in adoption of many of the improvements and best practices TLS has on the web. Some claim this need to provide a solution for non-HTTP, non-web applications provides a motivation to continue pushing DNSSEC deployment.
I disagree, I think it provides a motivation to instead double-down on moving those applications to TLS. TLS as the new TCP.
The problem is that costs of deploying and operating DNSSEC are largely fixed regardless of how many protocols you are intending to protect with it, and worse, the negative side-effects of DNSSEC deployment can and will easily spill over to affect zones and protocols that don t want or need DNSSEC s protection. To justify continued DNSSEC deployment and operation in this context means using a smaller set of benefits (just for the non-HTTP applications) to justify the already high costs of deploying DNSSEC itself, plus the cost of the risk that DNSSEC poses to the reliability to your websites. I don t see how that equation can ever balance, particularly when you evaluate it against the much lower costs of just turning on TLS for the rest of your non-HTTP protocols instead of deploying DNSSEC. MTA-STS is a worked example of how this can be achieved.
If you re still not convinced, consider that even DNS itself is considering moving to TLS (via DoT and DoH) in order to add the confidentiality/privacy attributes the protocol currently lacks. I m not a huge fan of the latency implications of these approaches, but the ongoing discussion shows that clever solutions and mitigations for that may exist.
DoT/DoH solve distinct problems from DNSSEC and in principle should be used in combination with it, but in a world where DNS itself is relying on TLS and therefore has eliminated the majority of spoofing and cache poisoning attacks through DoT/DoH deployment the benefit side of the DNSSEC equation gets smaller and smaller still while the costs remain the same.
OK, but better software or more careful operations can reduce DNSSEC s cost
Some see the current DNSSEC costs simply as teething problems that will reduce as the software and tooling matures to provide more automation of the risky processes and operational teams learn from their mistakes or opt to simply transfer the risk by outsourcing the management and complexity to larger providers to take care of.
I don t find these arguments compelling. We ve already had 15+ years to develop improved software for DNSSEC without success. What s changed that we should expect a better outcome this year or next? Nothing.
Even if we did have better software or outsourced operations, the approach is still only hiding the costs behind automation or transferring the risk to another organisation. That may appear to work in the short-term, but eventually when the time comes to upgrade the software, migrate between providers or change registrars the debt will come due and incidents will occur.
The problem is the complexity of the protocol itself. No amount of software improvement or outsourcing addresses that.
After 15+ years of trying, I think it s worth considering that combining cryptography, caching and distributed consensus, some of the most fundamental and complex computer science problems, into a slow-moving and hard to evolve low-level infrastructure protocol while appropriately balancing security, performance and reliability appears to be beyond our collective ability.
That doesn t have to be the end of the world, the improvements achieved in the TLS ecosystem over the same time frame provide a positive counter example - perhaps DNSSEC is simply focusing our attention at the wrong layer of the stack.
Ideally secure DNS data would be something we could have, but if the complexity of DNSSEC is the price we have to pay to achieve it, I m out. I would rather opt to remain with the simpler yet insecure DNS protocol and compensate for its short comings at higher transport or application layers where experience shows we are able to more rapidly improve and develop our security capabilities.
Summing up
For the vast majority of domains and use-cases there is simply no net benefit to deploying DNSSEC in 2023. I d even go so far as to say that if you ve already signed your zones, you should (carefully) move them back to being unsigned - you ll reduce the complexity of your operating environment and lower your risk of availability loss triggered by DNS. Your users will thank you.
The threats that DNSSEC defends against are already amply defended by the now mature and still improving TLS ecosystem at the application layer, and investing in further improvements here carries far more return than deployment of DNSSEC.
For TLDs, like .nz whose outage triggered this post, DNSSEC is not going anywhere and investment in mitigating its complexities and risks is an unfortunate burden that must be shouldered. While the full incident report of what went wrong with .nz is not yet available, the interim report already hints at some useful insights. It is important that InternetNZ publishes a full and comprehensive review so that the full set of learnings and improvements this incident can provide can be fully realised by .nz and other TLD operators stuck with the unenviable task of trying to safely operate DNSSEC.
Postscript
After taking a few days to draft and edit this post, I ve just stumbled across a presentation from the well respected Geoff Huston at last weeks RIPE86 meeting. I ve only had time to skim the slides (video here) - they don t seem to disagree with my thinking regarding the futility of the current state of DNSSEC, but also contain some interesting ideas for what it might take for DNSSEC to become a compelling proposition.
Probably worth a read/watch!
Pearls of Luthra
Pearls of Luthra is the first book by Brian Jacques and I think I am going to be a fan of his work. This particular book you have to be wary of. While it is a beautiful book with quite a few illustrations, I have to warn that if you are somebody who feels hungry at the very mention of food, then you will be hungry throughout the book. There isn t a single page where food isn t mentioned and not just any kind of food, the kind of food that is geared towards sweet tooth. So if you fancy tarts or chocolates or anything sweet you will right at home. The book also touches upon various teas and wines and various liquors but food is where it shines in literally. The tale is very much like a Harry Potter adventure but isn t as dark as HP was. In fact, apart from one death and one ear missing rest of our heroes and heroines and there are quite a few. I don t want to give too much away as it s a book to be treasured.
Dahaad
Dahaad (the roar) is Sonakshi Sinha s entry in OTT/Web Series. The stage is set somewhere in North India while the exploits are based on a real life person called Cyanide Mohan who killed 20 women between 2005-2009. In the web series however, the antagonist s crimes are done over a period of 12 years and has 29 women as his victims. Apart from that it s pretty much a copy of what was done by the person above. It s a melting pot of a series which quite a few stories enmeshed along with the main one. The main onus and plot of the movie is about women from lower economic and caste order whose families want them to be wed but cannot due to huge demands for dowry. Now in such a situation, if a person were to give them a bit of attention, promise marriage and ask them to steal a bit and come with him and whatever, they will do it. The same modus operandi was done by Cynaide Mohan. He had a car that was not actually is but used it show off that he s from a richer background, entice the women, have sex, promise marriage and in the morning after pill there will be cynaide which the women unwittingly will consume.
This is also framed by the protagonist Sonakshi Sinha to her mother as her mother is also forcing her to get married as she is becoming older. She shows some of the photographs of the victims and says that while the perpetrator is guilty but so is the overall society that puts women in such vulnerable positions. AFAIK, that is still the state of things. In fact, there is a series called Indian Matchmaking that has all the snobbishness that you want. How many people could have a lifestyle like the ones shown in that, less than 2% of the population. It s actually shows like the above that make the whole thing even more precarious
Apart from it, the show also shows prejudice about caste and background. I wouldn t go much into it as it s worth seeing and experiencing.
Tetris
Tetris in many a ways is a story of greed. It s also a story of a lone inventor who had to wait almost 20 odd years to profit from his invention. Forbes does a marvelous job of giving some more background and foreground info. about Tetris, the inventor and the producer that went to strike it rich. It also does share about copyright misrepresentation happens but does nothing to address it. Could talk a whole lot but better to see the movie and draw your own conclusions. For me it was 4/5.
Discord
Discord became Discord 2.0 and is a blank to me. A blank page. Can t do anything. First I thought it was a bug. Waited for a few days as sometimes webservices do fix themselves. But two weeks on and it still wasn t fixed then decided to look under. One of the tools in Firefox is Web Developer Tools ( CTRL+Shift+I) that tells you if an element of a page is not appearing or at least gives you a hint. To me it gave me the following
Content Security Policy: Ignoring 'unsafe-inline' within script-src or style-src: nonce-source or hash-source specified Content Security Policy: The page s settings blocked the loading of a resource at data:text/css,%0A%20%20%20%20%20%20%20%2 ( style-src ). data:44:30 Content Security Policy: Ignoring 'unsafe-inline' within script-src or style-src: nonce-source or hash-source specified TypeError: AudioContext is not a constructor 138875 https://discord.com/assets/cbf3a75da6e6b6a4202e.js:262 l https://discord.com/assets/f5f0b113e28d4d12ba16.js:1ed46a18578285e5c048b.js:241:118
What is being done is dom.webaudio.enabled being disabled in Firefox.
Then on a hunch, searched on reddit and saw the following. Be careful while visiting the link as it s labelled NSFW although to my mind there wasn t anything remotely NSFW about it. They do mention using another tool AudioContext Fingerprint Defender which supposedly fakes or spoofs an id. As this add-on isn t tracked by Firefox privacy team it s hard for me to say anything positive or negative.
So, in the end I stopped using discord as the alternative was being tracked by them
Last but not the least, saw this about a week back. Sooner or later this had to happen as Elon tries to make money off Twitter.
This year I attended Debian Reunion Hamburg (aka MiniDebConf Germany) for the second time. My goal for this MiniDebConf was just to talk to people and make the most of the time I have there. No other specific plans or goals. Despite this simple goal, it was a very productive and successful event for me.
Tuesday 23rd:
Arrived much later than planned after about 18h of travel, went to bed early.
Wednesday 24th:
Was in a discussion about individual package maintainership.
Was in a discussion about the nature of Technical Committee.
Co-signed a copy of The Debian System book along with the other DDs
Submitted a BoF request for people who are present to bring issues to the attention of the DPL (and to others who are around).
Noticed I still had a blog entry draft about this event last year, and posted it just to get it done.
Had a stand-up meeting, was nice to see what everyone was working on.
Had some event budgeting discussions with Holger.
Worked a bit on a talk I haven t submitted yet called Current events (it s slightly punny, get it?) it s still very raw but I m passively working on it just in case we need a backup talk over the weekend.
Had a discussion over lunch with someone who runs their HPC on Debian and learned about Octopus and Pac.
Was in a discussion about amd64 build times on our buildds and referred them to DSA. I also e-mailed DSA to ask them if there s anything we can do to improve build times (since it affects both productivity and motivation).
Did some premium cola tasting with andrewsh
Had a discussion with Ilu about installers (and luks2 issues in Calamares), accessibility and organisational stuff.
Thursday 25th:
Spent quite a chunk of the morning in a usrmerge BoF. I m very impressed by the amount of reading and research the people in the BoF did and gathering all the facts/data, it seems that there is now a way forward that will fix usrmerge in Debian in a way that could work for everyone, an extensive summary/proposal will be posted to debian-devel as soon as possible.
Mind was in zombie mode. So I did something easy and upgraded the host running this blog and a few other hosts to bookworm to see what would break.
Cheese and wine party, which resulted in a mao party that ran waaaay too late.
Friday 26th:
Daytrip
Was very saddened to learn that the Metallica concert in Hamburg that day was not a daytrip option.
Had a BoF where we had an open discussion about things on our collective minds (Debian Therapy Session).
Had a session on upcoming legislature in the EU (like CRA).
Some web statistics with MrFai.
Talked to Marc Haber about a DebConf bid for Heidelberg for DebConf 25.
Closing session.
Monday 29th:
Started the morning with Helmut and Jochen convincing me switch from cowbuilder to sbuild (I m tentatively sold, the huge new plus is that you don t need schroot anymore, which trashed two of my systems in the past and effectively made sbuild a no-go for me until now).
Dealt with more laptop hardware failures, removing a stick of RAM seems to have solved that for now!
Das is nicht gut.
Dealt with some delegation issues for release team and publicity team.
Attended my last stand-up meeting.
Wrapped things up, blogged about the event. Probably forgot to list dozens of things in this blog entry. It is fine.
Tuesday 30th:
Didn t attend the last day, basically a travel day for me.
Thank you to Holger for organising this event yet again!
What is Convergence
In 2013 Kyle Rankin (at the time Linux Journal columnist and CSO of Purism) wrote a Linux Journal article about Linux convergence [1] (which means using a phone and a dock to replace a desktop) featuring the Nokia N900 smart phone and a chroot environment on the Motorola Droid 4 Android phone. Both of them have very limited hardware even by the standards of the day and neither of which were systems I d consider using all the time. None of the Android phones I used at that time were at all comparable to any sort of desktop system I d want to use.
Hardware for Convergence Comparing a Phone to a Laptop
The first hardware issue for convergence is docks and other accessories to attach a small computer to hardware designed for larger computers. Laptop docks have been around for decades and for decades I haven t been using them because they have all been expensive and specific to a particular model of laptop. Having an expensive dock at home and an expensive dock at the office and then replacing them both when the laptop is replaced may work well for some people but wasn t something I wanted to do. The USB-C interface supports data, power, and DisplayPort video over the same cable and now USB-C docks start at about $20 on eBay and dock functionality is built in to many new monitors. I can take a USB-C device to the office of any large company and know there s a good chance that there will be a USB-C dock ready for me to use. The fact that USB-C is a standard feature for phones gives obvious potential for convergence.
The next issue is performance. The Passmark benchmark seems like a reasonable way to compare CPUs [2]. It may not be the best benchmark but it has an excellent set of published results for Intel and AMD CPUs. I ran that benchmark on my Librem5 [3] and got a result of 507 for the CPU score. At the end of 2017 I got a Thinkpad X301 [4] which rates 678 on Passmark. So the Librem5 has 3/4 the CPU power of a laptop that was OK for my use in 2018. Given that the X301 was about the minimum specs for a PC that I can use (for things other than serious compiles, running VMs, etc) the Librem 5 has 3/4 the CPU power, only 3G of RAM compared to 6G, and 32G of storage compared to 64G. Here is the Passmark page for my Librem5 [5]. As an aside my Libnrem5 is apparently 25% faster than the other results for the same CPU did the Purism people do something to make their device faster than most?
For me the Librem5 would be at the very low end of what I would consider a usable desktop system. A friend s N900 (like the one Kyle used) won t complete the Passmark test apparently due to the Extended Instructions (NEON) test failing. But of the rest of the tests most of them gave a result that was well below 10% of the result from the Librem5 and only the Compression and CPU Single Threaded tests managed to exceed 1/4 the speed of the Librem5. One thing to note when considering the specs of phones vs desktop systems is that the MicroSD cards designed for use in dashcams and other continuous recording devices have TBW ratings that compare well to SSDs designed for use in PCs, so swap to a MicroSD card should work reasonably well and be significantly faster than the hard disks I was using for swap in 2013!
In 2013 I was using a Thinkpad T420 as my main system [6], it had 8G of RAM (the same as my current laptop) although I noted that 4G was slow but usable at the time. Basically it seems that the Librem5 was about the sort of hardware I could have used for convergence in 2013. But by today s standards and with the need to drive 4K monitors etc it s not that great.
The N900 hardware specs seem very similar to the Thinkpads I was using from 1998 to about 2003. However a device for convergence will usually do more things than a laptop (IE phone and camera functionality) and software had become significantly more bloated in 1998 to 2013 time period. A Linux desktop system performed reasonably with 32MB of RAM in 1998 but by 2013 even 2G was limiting.
Software Issues for Convergence
Jeremiah Foster (Director PureOS at Purism) wrote an interesting overview of some of the software issues of convergence [7]. One of the most obvious is that the best app design for a small screen is often very different from that for a large screen. Phone apps usually have a single window that shows a view of only one part of the data that is being worked on (EG an email program that shows a list of messages or the contents of a single message but not both). Desktop apps of any complexity will either have support for multiple windows for different data (EG two messages displayed in different windows) or a single window with multiple different types of data (EG message list and a single message). What we ideally want is all the important apps to support changing modes when the active display is changed to one of a different size/resolution. The Purism people are doing some really good work in this regard. But it is a large project that needs to involve a huge range of apps.
The next thing that needs to be addressed is the OS interface for managing apps and metadata. On a phone you swipe from one part of the screen to get a list of apps while on a desktop you will probably have a small section of a large monitor reserved for showing a window list. On a desktop you will typically have an app to manage a list of items copied to the clipboard while on Android and iOS there is AFAIK no standard way to do that (there is a selection of apps in the Google Play Store to do this sort of thing).
Purism has a blog post by Sebastian Krzyszkowiak about some of the development of the OS to make it work better for convergence and the status of getting it in Debian [8].
The limitations in phone hardware force changes to the software. Software needs to use less memory because phone RAM can t be upgraded. The OS needs to be configured for low RAM use which includes technologies like the zram kernel memory compression feature.
Security
When mobile phones first came out they were used for less secret data. Loss of a phone was annoying and expensive but not a security problem. Now phone theft for the purpose of gaining access to resources stored on the phone is becoming a known crime, here is a news report about a thief stealing credit cards and phones to receive the SMS notifications from banks [9]. We should expect that trend to continue, stealing mobile devices for ssh keys, management tools for cloud services, etc is something we should expect to happen.
A problem with mobile phones in current use is that they have one login used for all access from trivial things done in low security environments (EG paying for public transport) to sensitive things done in more secure environments (EG online banking and healthcare). Some applications take extra precautions for this EG the Android app I use for online banking requires authentication before performing any operations. The Samsung version of Android has a system called Knox for running a separate secured workspace [10]. I don t think that the Knox approach would work well for a full Linux desktop environment, but something that provides some similar features would be a really good idea. Also running apps in containers as much as possible would be a good security feature, this is done by default in Android and desktop OSs could benefit from it.
The Linux desktop security model of logging in to a single account and getting access to everything has been outdated for a long time, probably ever since single-user Linux systems became popular. We need to change this for many reasons and convergence just makes it more urgent.
Conclusion
I have become convinced that convergence is the way of the future. It has the potential to make transporting computers easier, purchasing cheaper (buy just a phone and not buy desktop and laptop systems), and access to data more convenient. The Librem5 doesn t seem up to the task for my use due to being slow and having short battery life, the PinePhone Pro has more powerful hardware and allegedly has better battery life [11] so it might work for my needs. The PinePhone Pro probably won t meet the desktop computing needs of most people, but hardware keeps getting faster and cheaper so eventually most people could have their computing needs satisfied with a phone.
The current state of software for convergence and for Linux desktop security needs some improvement. I have some experience with Linux security so this is something I can help work on.
To work on improving this I asked Linux Australia for a grant for me and a friend to get PinePhone Pro devices and a selection of accessories to go with them. Having both a Librem5 and a PinePhone Pro means that I can test software in different configurations which will make developing software easier. Also having a friend who s working on similar things will help a lot, especially as he has some low level hardware skills that I lack.
Linux Australia awarded the grant and now the PinePhones are in transit. Hopefully I will have a PinePhone in a couple of weeks to start work on this.
It wouldn t be inaccurate to say that I ve had a lot on my plate in the last few years, and that I have a *huge* backlog of little tasks to finish. Just last week, I finally got to all my keysigning from DebConf22. This week, I m at MiniDebConf Germany in Hamburg. It s the second time I m here! And it s great already. Last year I drafted a blog entry, but never got around to publishing it. So, in order to mentally tick off yet another thing, here follows a somewhat imperfect (I had to delete a lot of short-hand because I didn t know what it means anymore), but at least published post about my activities from a year ago.
This week (well, last year) I attended my first ever in-person MiniDebConf and MiniDebCamp in Hamburg, Germany. The last time I was in Germany was 7 years ago for DebConf15 (or at time of publishing, actually, last year for this same event).
My focus for the week was to work on Debian live related stuff.
In preparation for the week I tried to fix/close as many Calamares bugs as I could, so before the event I closed:
File calamares upstream issue #1944 Calamares allows me to select a username of root for Debian bug #976617.
File calamares upstream issue #1945 Calamares needs support for high DPI for Debian bug #992162.
Comment on calamares bug #1005212 Calamares installer fails at partitioning disks requesting further info.
Close calamares bug #1009876 There is no /tmp item in the list during the partitioning step in the debian calamares installer /tmp partitions can be created, not a bug, really just a small UI issue.
Close calamares bug #974998 SegFault when clicked on Create in manual partitioning , not reproducible in bullseye.
Close calamares bug #971266 Debian fails to start when /home is encrypted during installation this works fine since bullseye.
Close calamares bug #976617 Calamares allows me to select a username of root has since been fixed upstream.
Monday to Friday we worked together on various issues, and the weekend was for talks.
On Monday morning, I had a nice discussion with Roland Clobus who has been working on making Debian live images reproducible. He s also been working on testing Debian Live on openqa.debian.net. We re planning on integrating his work so that Debian 12 live images will be reproducible. For automated testing on openqa, it will be ongoing work, one blocker has been that snapshots.debian.org limits connections after a while, so builds on there start failing fast.
On Monday afternoon, I went ahead and uploaded the latest Calamares hotfix (Calamares 3.2.58.1-1) release that fixes a UI issue on the partitioning screen where it could get stuck. On 15:00 we had a stand-up meeting where we introduced ourselves and talked a bit about our plans. It was great to see how many people could benefit from each other being there. For example, someone wanting to learn packaging, another wanting to improve packaging documentation, another wanting help with packaging something written in Rust, another wanting to improve Rust packaging in general and lots of overlap when it comes to reproducible builds! I also helped a few people with some of their packaging issues.
On Monday evening, someone in videoteam managed to convince me to put together a loopy loop for this MiniDebConf. There s really wasn t enough time to put together something elaborate, but I put something together based on the previous loopy with some experiments that I ve been working on for the upcoming DC22 loopy, and we can use this loop to do a call for content for the DC22 loop.
On Tuesday morning had some chats with urbec and Ilu,Tuesday afternoon talked to MIA team about upcoming removals. Did some admin on debian.ch payments for hosting. On Tuesday evening worked on live image stuff (d-i downloader, download module for dmm).
On Wednesday morning I slept a bit late, then had to deal with some DPL admin/legal things. Wednesday afternoon, more chats with people.
On Thursday: Talked to a bunch more people about a lot of issues, got loopy in a reasonably shape, edited and published the Group photo!
On Friday: prepared my talk slides, learned about Brave (https://github.com/bbc/brave) It initially looked like a great compositor for DebConf video stuff (and possible replacement for OBS, but it turned out it wasn t really maintained upstream). In the evening we had the Cheese and Wine party, where lots of deliciousness was experienced.
On Saturday, I learned from Felix s talk that Tensorflow is now in experimental! (and now in 2023 I checked again and that s still the case, although it hasn t made it s way in unstable yet, hopefully that improves over the trixie cycle)
I know most of the people who attended quite well, but it was really nice to also see a bunch of new Debianites that I ve only seen online before and to properly put some faces to names. We also had a bunch of enthusiastic new contributors and we did some key signing.
The climate apocalypse has happened. Humans woke up to the danger, but a
little bit too late. Over one billion people died. But the world on the
other side of that apocalypse is not entirely grim. The corporations
responsible for so much of the damage have been pushed out of society and
isolated on their independent "aislands," traded with only grudgingly for
the few commodities the rest of the world has not yet learned how to
manufacture without them. Traditional governments have largely collapsed,
although they cling to increasingly irrelevant trappings of power. In
their place arose the watershed networks: a new way of living with both
nature and other humans, built around a mix of anarchic consensus and
direct democracy, with conservation and stewardship of the natural
environment at its core.
Therefore, when the aliens arrive near Bear Island on the Potomac River,
they're not detected by powerful telescopes and met by military jets.
Instead, their waste sets off water sensors, and they're met by the two
women on call for alert duty, carrying a nursing infant and backed by the
real-time discussion and consensus technology of the watershed's dandelion
network. (Emrys is far from the first person to name something a
"dandelion network," so be aware that the usage in this book seems
unrelated to the charities or blockchain network.)
This is a first contact novel, but it's one that skips over the typical
focus of the subgenre. The alien Ringers are completely fluent in English
down to subtle nuance of emotion and connotation (supposedly due to
observation of our radio and TV signals), have translation devices, and in
some cases can make our speech sounds directly. Despite significantly
different body shapes, they are immediately comprehensible; differences
are limited mostly to family structure, reproduction, and social norms.
This is Star Trek first contact, not the type more typical of
written science fiction. That feels unrealistic, but it's also obviously
an authorial choice to jump directly to the part of the story that Emrys
wants to write.
The Ringers have come to save humanity. In their experience,
technological civilization is inherently incompatible with planets.
Technology will destroy the planet, and the planet will in turn destroy
the species unless they can escape. They have reached other worlds
multiple times before, only to discover that they were too late and
everyone is already dead. This is the first time they've arrived in time,
and they're eager to help humanity off its dying planet to join them in
the Dyson sphere of
space habitats they are constructing. Planets, to them, are a nest and a
launching pad, something to eventually abandon and break down for spare
parts.
The small, unexpected wrinkle is that Judy, Carol, and the rest of their
watershed network are not interested in leaving Earth. They've finally
figured out the most critical pieces of environmental balance. Earth is
going to get hotter for a while, but the trend is slowing. What they're
doing is working. Humanity would benefit greatly from Ringer technology
and the expertise that comes from managing closed habitat ecosystems, but
they don't need rescuing.
This goes over about as well as a toddler saying that playing in the road
is perfectly safe.
This is a fantastic hook for a science fiction novel. It does exactly
what a great science fiction premise should do: takes current concerns
(environmentalism, space boosterism, the debatable primacy of humans as a
species, the appropriate role of space colonization, the tension between
hopefulness and doomcasting about climate change) and uses the freedom of
science fiction to twist them around and come at them from an entirely
different angle.
The design of the aliens is excellent for this purpose. The Ringers are
not one alien species; they are two, evolved on different planets in the
same system. The plains dwellers developed space flight first and went to
meet the tree dwellers, and while their relationship is not entirely
without hierarchy (the plains dwellers clearly lead on most matters), it's
extensively symbiotic. They now form mixed families of both species, and
have a rich cultural history of stories about first contact, interspecies
conflicts and cooperation, and all the perils and misunderstandings that
they successfully navigated. It makes their approach to humanity more
believable to know that they have done first contact before and are
building on a model. Their concern for humanity is credibly sincere. The
joining of two species was wildly successful for them and they truly want
to add a third.
The politics on the human side are satisfyingly complicated. The
watershed network may have made first contact, but the US government (in
the form of NASA) is close behind, attempting to lean on its widely
ignored formal power. The corporations are farther away and therefore
slower to arrive, but the alien visitors have a damaged ship and need
space to construct a subspace beacon and Asterion is happy to offer a site
on one of its New Zealand islands. The corporate representatives are
salivating at the chance to escape Earth and its environmental regulation
for uncontrolled space construction and a new market of trillions of
Ringers. NASA's attitude is more measured, but their representative is
easily persuaded that the true future of humanity is in space. The work
the watershed networks are doing is difficult, uncertain, and involves a
lot of sacrifice, particularly for corporate consumer lifestyles. With
such an attractive alien offer on the table, why stay and work so hard for
an uncertain future? Maybe the Ringers are right.
And then the dandelion networks that the watersheds use as the core of
their governance and decision-making system all crash.
The setup was great; I was completely invested. The execution was more
mixed. There are some things I really liked, some things that I thought
were a bit too easy or predictable, and several places where I wish Emrys
had dug deeper and provided more detail. I thought the last third of the
book fizzled a little, although some of the secondary characters Emrys
introduces are delightful and carry the momentum of the story when the
politics feel a bit lacking.
If you tried to form a mental image of ecofeminist political science
fiction with 1970s utopian sensibilities, but updated for the concerns of
the 2020s, you would probably come very close to the politics of the
watershed networks. There are considerably more breastfeedings and diaper
changes than the average SF novel. Two of the primary characters are
transgender, but with very different experiences with transition. Pronoun
pins are an ubiquitous article of clothing. One of the characters has a
prosthetic limb. Another character who becomes important later in the
story codes as autistic. None of this felt gratuitous; the characters do
come across as obsessed with gender, but in a way that I found believable.
The human diversity is well-integrated with the story, shapes the
characters, creates practical challenges, and has subtle (and sometimes
not so subtle) political ramifications.
But, and I say this with love because while these are not quite my people
they're closely adjacent to my people, the social politics of this book
are a very specific type of white feminist collaborative utopianism. When
religion makes an appearance, I was completely unsurprised to find that
several of the characters are Jewish. Race never makes a significant
appearance at all. It's the sort of book where the throw-away references
to other important watershed networks includes African ones, and the
characters would doubtless try to be sensitive to racial issues if they
came up, but somehow they never do. (If you're wondering if there's
polyamory in this book, yes, yes there is, and also I suspect you know
exactly what culture I'm talking about.)
This is not intended as a criticism, just more of a calibration. All
science fiction publishing houses could focus only on this specific
political perspective for a year and the results would still be dwarfed by
the towering accumulated pile of thoughtless paeans to capitalism.
Ecofeminism has a long history in the genre but still doesn't show up in
that many books, and we're far from exhausting the space of possibilities
for what a consensus-based politics could look like with extensive
computer support. But this book has a highly specific point of view,
enough so that there won't be many thought-provoking surprises if you're
already familiar with this school of political thought.
The politics are also very earnest in a way that I admit provoked a bit of
eyerolling. Emrys pushes all of the political conflict into the contrasts
between the human factions, but I would have liked more internal
disagreement within the watershed networks over principles rather than
tactics. The degree of ideological agreement within the watershed group
felt a bit unrealistic. But, that said, at least politics truly matters
and the characters wrestle directly with some tricky questions. I would
have liked to see more specifics about the dandelion network and the exact
mechanics of the consensus decision process, since that sort of thing is
my jam, but we at least get more details than are typical in science
fiction. I'll take this over cynical
libertarianism any day.
Gender plays a huge role in this story, enough so that you should avoid
this book if you're not interested in exploring gender conceptions. One
of the two alien races is matriarchal and places immense social value on
motherhood, and it's culturally expected to bring your children with you
for any important negotiation. The watersheds actively embrace this, or
at worst find it comfortable to use for their advantage, despite a few
hints that the matriarchy of the plains aliens may have a very serious
long-term demographic problem. In an interesting twist, it's the
mostly-evil corporations that truly challenge gender roles, albeit by
turning it into an opportunity to sell more clothing.
The Asterion corporate representatives are, as expected, mostly the
villains of the plot: flashy, hierarchical, consumerist, greedy, and
exploitative. But gender among the corporations is purely a matter of
public performance, one of a set of roles that you can put on and off as
you choose and signal with clothing. They mostly use neopronouns, change
pronouns as frequently as their clothing, and treat any question of body
plumbing as intensely private. By comparison, the very 2020 attitudes of
the watersheds towards gender felt oddly conservative and essentialist,
and the main characters get flustered and annoyed by the ever-fluid
corporate gender presentation. I wish Emrys had done more with this.
As you can tell, I have a lot of thoughts and a lot of quibbles. Another
example: computer security plays an important role in the plot and was
sufficiently well-described that I have serious questions about the system
architecture and security model of the dandelion networks. But, as with
decision-making and gender, the more important takeaway is that Emrys
takes enough risks and describes enough interesting ideas that there's a
lot of meat here to argue with. That, more than getting everything right,
is what a good science fiction novel should do.
A Half-Built Garden is written from a very specific political
stance that may make it a bit predictable or off-putting, and I thought
the tail end of the book had some plot and resolution problems, but
arguing with it was one of the more intellectually satisfying science
fiction reading experiences I've had recently. You have to be in the
right mood, but recommended for when you are.
Rating: 7 out of 10
India Press Freedom
Just about a week back, India again slipped in the Freedom index, this time falling to 161 out of 180 countries. The RW again made lot of noise as they cannot fathom why it has been happening so. A recent news story gives some idea. Every year NCRB (National Crime Records Bureau) puts out its statistics of crimes happening across the country. The report is in public domain. Now according to report shared, around 40k women from Gujarat alone disappeared in the last five years. This is a state where BJP has been ruling for the last 30 odd years. When this report became viral, almost all national newspapers the news was censored/blacked out. For e.g. check out newindianexpress.com, likewise TOI and other newspapers, the news has been 404. The only place that you can get that news is in minority papers like siasat. But the story didn t remain till there. While the NCW (National Commission of Women) pointed out similar stuff happening in J&K, Gujarat Police claimed they got almost 39k women back. Now ideally, it should have been in NCRB data as an addendum as the report can be challenged. But as this news was made viral, nobody knows the truth or false in the above. What BJP has been doing is whenever they get questioned, they try to muddy the waters like that. And most of the time, such news doesn t make to court so the party gets a freebie in a sort as they are not legally challenged. Even if somebody asks why didn t Gujarat Police do it as NCRB report is jointly made with the help of all states, and especially with BJP both in Center and States, they cannot give any excuse. The only excuse you see or hear is whataboutism unfortunately
Profiteering on I.T. Hardware
I was chatting with a friend yesterday who is an enthusiast like me but has been more alert about what has been happening in the CPU, motherboard, RAM world. I was simply shocked to hear the prices of motherboards which are three years old, even a middling motherboard. For e.g. the last time I bought a mobo, I spent about 6k but that was for an ATX motherboard. Most ITX motherboards usually sold for around INR 4k/- or even lower. I remember Via especially as their mobos were even cheaper around INR 1.5-2k/-. Even before pandemic, many motherboard manufacturers had closed down shop leaving only a few in the market. As only a few remained, prices started going higher. The pandemic turned it to a seller s market overnight as most people were stuck at home and needed good rigs for either work or leisure or both. The manufacturers of CPU, motherboards, GPU s, Powersupply (SMPS) named their prices and people bought it. So in 2023, high prices remained while warranty periods started coming down. Governments also upped customs and various other duties. So all are in hand in glove in the situation. So as shared before, what I have been offered is a 4 year motherboard with a CPU of that time. I haven t bought it nor do I intend to in short-term future but extremely disappointed with the state of affairs
AMD Issues
It s just been couple of hard weeks apparently for AMD. The first has been the TPM (Trusted Platform Module) issue that was shown by couple of security researchers. From what is known, apparently with $200 worth of tools and with sometime you can hack into somebody machine if you have physical access. Ironically, MS made a huge show about TPM and also made it sort of a requirement if a person wanted to have Windows 11. I remember Matthew Garett sharing about TPM and issues with Lenovo laptops. While AMD has acknowledged the issue, its response has been somewhat wishy-washy. But this is not the only issue that has been plaguing AMD. There have been reports of AMD chips literally exploding and again AMD issuing a somewhat wishy-washy response. Asus though made some changes but is it for Zen4 or only 5 parts, not known. Most people are expecting a recession in I.T. hardware this year as well as next year due to high prices. No idea if things will change, if ever
Gray Mountain John Grisham
I have been perusing John Grisham s books, some read and some re-read again. Almost all of the books that Mr. Grisham wrote are relevant even today. The Gray Mountain talks about how mountain top removal was done in Applachia, the U.S. (South). In fact NASA made a summary which either was borrowed from this book or the author borrowed from NASA, either could be true although seems it might be the former. And this is when GOI just made a new Forest Conservation Bill 2023 which does the opposite. There are many examples of the same, the latest from my own city as an e.g. Vetal Tekdi is and was a haven for people animals, birds all kinds of ecosystem and is a vital lung of the city, one of the few remaining green spaces in the city but BJP wants to commercialize it as it has been doing for everything, I haven t been to the Himalayas since 4-5 years back as I hear the rape of the land daily. Even after Joshimath tragedy, if people are not opening the eyes what can I do The more I say, the more depressed I will become so will leave it for now. In many ways the destruction seems similar to the destruction that happened in Brazil under Jair Bolsonaro. So as can be seen from what I have shared this book was mostly about environment and punitive damages and also how punitive damages have been ceiling in America (South). This was done via lobbying by the coal groups and apparently destroyed people s lives, communities, even whole villages. It also shared how most people called black lung and how those claims had been denied by Coal Companies all the time. And there are hardly any unions. While the book itself is a fiction piece, there is a large amount of truth in it. And that is one of the reasons people write a fiction book. You could write about reality using fictional names and nobody can sue you while you set the reality as it is. In many ways, it is a tell-all.
The Testament John Grisham
One of the things I have loved about John Grisham is he understands human condition. In this book it starts with an eccentric billionaire who makes a will which leaves all his property to an illegitimate child who coincidentally also lives in Brazil, she is a missionary. The whole book is about human failings as well as about finding the heir. I am not going to give much detail as the book itself is fun.
The Appeal John Grisham
In this, we are introduced to a company that does a chemical spill for decades and how that leads to lobbying and funding Judicial elections. It does go into quite a bit of length how private money coming from Big business does all kind of shady things to get their person elected to the Supreme Court. Sadly, this seems to happen all the time, for e.g. two weeks ago. This piece from the Atlantic also says the same. Again, won t tell as there is a bit of irony at the end of the book.
The Rainmaker John Grisham
This in short is about how Insurance Companies stiff people. It s a wonderful story that has all people in grey including our hero. An engaging book that sorta tells how the Insurance Industry plays the game. In India, the companies are safe as they ask for continuance for years together and their object is to delay the hearings till the grandchildren are not alive unlike in the U.S. or UK. It also does tell how more lawyers are there then required. Both of which are the same in my country.
The Litigators John Grisham
This one is about Product Liability, both medicines as well as toys for young kids. What I do find funny a bit is how the law in States allows people to file cases but doesn t protect people while in EU they try their best that if there is any controversy behind any medicine or product, they will simply ban it. Huge difference between the two cultures.
Evolution no longer part of Indian Education
A few days ago, NCERT (one of the major bodies) that looks into Indian Education due to BJP influence has removed Darwin s Theory of Evolution. You can t even debate because the people do not understand adaptability. So the only conclusion is that Man suddenly appeared out of nowhere. If that is so, then we are the true aliens. They discard the notion that we and Chimpanzees are similar. Then they also have to discard this finding that genetically we are 96% similar.
Rust is a hugely popular compiled programming language and accelerating it was an important goal for Firebuild for some time.
Firebuild s v0.8.0 release finally added Rust support in addition to numerous other improvements including support for Doxygen, Intel s Fortran compiler and restored javac and javadoc acceleration.
Firebuild s Rust + Cargo support
Firebuild treats programs as black boxes intercepting C standard library calls and system calls. It shortcuts the program invocations that predictably generate the same outputs because the program itself is known to be deterministic and all inputs are known in advance. Rust s compiler, rustc is deterministic in itself and simple rustc invocations were already accelerated, but parallel builds driven by Cargo needed a few enhancements in Firebuild.
Cargo s jobserver
Cargo uses the Rust variant of the GNU Make s jobserver to control the parallelism in a build. The jobserver creates a file descriptor from which descendant processes can read tokens and are allowed to run one extra thread or parallel process per token received. After the extra threads or processes are finished the tokens must be returned by writing to the other file descriptor the jobserver created. The jobserver s file descriptors are shared with the descendant processes via environment variables:
Since getting tokens from the jobserver involves reading them as nondeterministic bytes from an inherited file descriptor this is clearly an operation that would depend on input not known in advance. Firebuild needs to make an exception and ignore jobserver usage related reads and writes since they are not meant to change the build results. However, there are programs not caring at all about jobservers and their file descriptors. They happily close the inherited file descriptors and open new ones with the same id, to use them for entirely different purposes. One such program is the widely used ./configure script, thus the case is far from being theoretical.
To stay on the safe side firebuild ignores jobserver fd usage only in programs which are known to use the jobserver properly. The list of the programs is now configurable in /etc/firebuild.conf and since rustc is on the list by default parallel Rust builds are accelerated out of the box!
Writable dependency dir
The other issue that prevented highly accelerated Rust builds was rustc s -L dependency=<dir> parameter. This directory is populated in a not fully deterministic order in parallel builds. Firebuild on the other hand hashes directory listings of open()-ed directories treating them as inputs assuming that the directory content will influence the intercepted programs outputs. As rustc programs started in parallel scanned the dependency directory in different states depending on what other Rust compilations finished already Firebuild had to store the full directory content as an input for each rustc cache entry resulting low hit rate when rustc was started again with otherwise identical inputs.
The solution here is ignoring rustc scanning the dependency directory, because the dependencies actually used are still treated as input and are checked when shortcutting rustc. With that implemented in firebuild, too, librsvg s build that uses Rust and Cargo can be accelerated by more than 90%, even on a system having 12 cores/24 threads!:
Firebuild accelerating librsvg s Rust + Cargo build from 38s to 2.8s on a Ryzen 5900X (12C/24T) system
On the way to accelerate anything
Firebuild s latest release incorporated more than 100 changes just from the last two months. They unlocked acceleration of Rust builds with Cargo, fixed Firebuild to work with the latest Java update that slightly changed its behavior, started accelerating Intel s Fortran compiler in addition to accelerating gfortran that was already supported and included many smaller changes improving the acceleration of other compilers and tools. If your favorite toolchain is not mentioned, there is still a good chance that it is already supported. Give Firebuild a try and tell us about your experience!
Update 1: Comparison to sccache came up in the reddit topic about Firebuild s Rust acceleration , thus by popular demand this is how sccache performs on the same project:
Firebuild 0.8.0 vs. sccache 0.4.2 accelerating librsvg s Rust + Cargo build
All builds took place on the same Ryzen 5900X system with 12 cores / 24 threads in LXC containers limited to using 1-12 virtual CPUs. A warm-up build took place before the vanilla (without any instrumentation) build to download and compile the dependency crates to measure only the project s build time. A git clean command cleared all the build artifacts from the project directory before each build and ./autogen.sh was run to measure only clean rebuilds (without autotools). See test configuration in the Firebuild performance test repository for more details and easy reproduction.
Firebuild had lower overhead than sccache (2.83% vs. 6.10% on 1 CPU and 7.71% vs. 22.05% on 12 CPUs) and made the accelerated build finish much faster (2.26% vs. 19.41% of vanilla build s time on 1 CPU and 7.5% vs. 27.4% of vanilla build s time on 12 CPUs).
I wrote the Ruby bindings for the Enquo Project, my attempt to bring queryable encryption to all databases, using the Rutie library.
Recently, I ve rewritten the bindings to use Magnus instead, and I thought I d put down my thoughts about the whole situation.
The Story So Far
The Enquo Project core cryptography is all written in Rust, as seems to be the vogue these days.
Rust is fast, safe, and easily interoperable with most of the rest of the modern software development ecosystem, making it a good choice as a language to implement the cryptographic primitives that Enquo needs, like Order-Revealing Encryption.
Of course, since not everyone writes their applications in Rust, we need to provide the functionality of the Enquo client in the languages that people do use, such as Ruby, Python, and so on.
Since re-writing all that cryptographic code in a myriad of languages would be tedious and error-prone, we instead provide bindings to the core Rust code.
These are just thin shims of code that translate the data types and function calls between Rust and the target language.
Wrong sort of shim, but canned language bindings would be handy
As I m most familiar with Ruby and its development ecosystem (particularly Ruby on Rails), it was natural that I d make Ruby bindings for Enquo as my first target.
Rummaging around, it seemed that Rutie was a good library to use, so off I went.
What are Rutie and Magnus, Anyway?
Both libraries share the same goal: provide the ability to write some Rust code, run that through a compiler, and produce something that can be loaded by the Ruby interpreter and used just like any other Ruby class.
They re both fairly high level interfaces, trying to abstract away much of the gory details, and do a lot of the common heavy lifting that can make writing bindings fiddly and annoying.
Things like mapping data types (like strings and integers) between Rust data types and the closest equivalents in Ruby.
This mapping never goes perfectly smoothly.
For example, Ruby integers don t have a fixed range of values they can represent you can store a huge number like 2256 more-or-less as easily as you can the number 12.
But Rust, being a lower-level language, only has a set of integer types that have fixed boundaries, like the u32 type, which can only store integers between zero and about four billion (232 - 1, to be precise).
There s also lots of little things that need to be just right, also, like translating the different memory management approaches of the languages, and dealing with a myriad of fiddly little issues like passing arguments and return values in and out of method calls, helpers for defining classes and methods (and pointing to the correct Rust functions), and so on.
This is what I imagine it looks like inside these libraries
(Herv Cozanet / Wikimedia Commons, CC-BY-SA)
All in all, these libraries are fairly significant pieces of work, and I m mighty glad that someone else has taken on the job of building (and maintaining!) them.
So Why the Change?
Good question.
It s important to say at the outset that there s nothing particularly wrong with Rutie.
I found using Rutie to be very straightforward, and the Ruby bindings came together very quickly and easily.
If someone chose to use Rutie for their project, I m sure they d have a good experience.
What made me take the time to rewrite using Magnus was a set of a few tiny things, which together gave me enough of a shove to do the work.
Firstly, I d had a hiccup with Rutie s support of newer versions of Ruby, particularly 3.2 (PR).
Also, I d hit a couple of segfault issues, which were ultimately caused by Ruby garbage-collecting data out from underneath me.
These were ultimately my fault, of course, but Rutie wasn t helping me out in avoiding the problems in the first place.
Finally, while Rutie helped translate data types, there was still a bit of boilerplate and ugliness that needed to be included.
This wasn t a showstopper, but I m appreciating the extra smoothness that Magnus provides here.
As an example, here s what s required in Rutie to get native Rust data types from Ruby method parameters (and the self reference to the current object):
fn enquo_field_decrypt_text(ciphertext_obj: RString, context_obj: RString) -> RString
let ciphertext = ciphertext_obj.to_str_unchecked();
let context = context_obj.to_vec_u8_unchecked();
let field = rbself.get_data(&*FIELD_WRAPPER);
// etc etc etc
The equivalent in Magnus is just the function signature:
You can also see there that Magnus signals an exception via the Result return value, while Rutie s approach to raising an exception involves poking the Ruby VM directly, which always struck me as a bit ugly.
There are several other minor things in Magnus (like its cleaner approach to wrapping structs so they can be stored in Ruby objects) that I m appreciating, too.
Never discount the power of ergonomics for making a happy developer.
The End Result
I spent a bit over half of last weekend doing the rewrite maybe ten hours of so.
Since Magnus did more type checking and data validation, and its approach to error handling was smoother, I took the opportunity to rewrite a bunch of Ruby wrapper code I d written (which just existed to check things like ranges of values and string encodings) into Rust, as well.
To make sure that the conversion was accurate, I added a heap more unit tests to the bindings.
I also took the opportunity to restructure the codebase to split the code for the different Ruby classes into separate files, which I hadn t done initially as the code had originally accreted, rather than being purposefully written.
All up, though, my rewrite ended up removing over 60 lines (excluding the extra specs I added):
Considering that I was translating from a higher level language into a lower level one, the removal of so much code is quite remarkable.
Magnus was able to automagically replace rather a lot of raise ArgumentError if something.isnt_right code in those .rb files.
So, in conclusion, if you, too, are building Ruby extensions in Rust, while Rutie is a solid choice (and you probably should stick with it if you re already using it), I highly recommend giving Magnus a look for your next extension.
The full title page of this book, in delightful 19th century style, is:
Once Upon a Tome: The Misadventures of a Rare Bookseller,
wherein the theory of the profession is partially explained, with a
variety of insufficient examples, by Oliver Darkshire. Interspersed
with several diverting FOOTNOTES of a comical nature, ably ILLUSTRATED
by Rohan Eason, PUBLISHED by W.W. Norton, and humbly proposed to the
consideration of the public in this YEAR 2023
That may already be enough to give you a feel for this book. Oliver
Darkshire works for Sotheran's Rare Books
and Prints in London, most notably running their
highly entertaining Twitter account.
This is his first book.
If you have been hanging out in the right corners of Twitter, you have
probably been anticipating the release of this book, and may already have
your own copy. If you have not (and to be honest it's increasingly
dubious whether there are right corners of Twitter left), you're in for a
treat. Darkshire has made Sotheran's a minor Twitter phenomenon due to
tweets like this:
CUSTOMER: oh thank heavens I have been searching for a rare book
expert with the knowledge to solve my complex problem
ME (extremely and unhelpfully specialized): ok well the words are
usually on the inside and I can see that's true here, so that's a good
start
I find I know lots of things until anyone asks me about it or there is
a question to answer, at which point I know nothing, I am a void, a
tragic bucket of ignorance
My hope was that Once Upon a Tome would be the same thing at book
length, and I am delighted to report that's exactly what it is. By the
time I finished reading the story of Darkshire's early training, I knew I
was going to savor every word.
The hardest part, though, lies in recording precisely in what ways a
book has survived the ravages of time. An entire lexicon of
book-related terminology has evolved over hundreds of years for
exactly this purpose terminology that means absolutely nothing to
the average observer. It's traditional to adopt this baroque language
when describing your books, for two reasons. The first is that the
specific language of the book trade allows you to be exceedingly
accurate and precise without using hundreds of words, and the second
is that the elegance of it serves to dull the blow a little. Most
rare books come with some minor defects, but that doesn't mean one has
to be rude about it.
You will learn something about rare book selling in this book, and more
about Darkshire's colleagues, but primarily this is a book-length attempt
to convey the slightly uncanny experience of working in a rare bookstore
in an entertaining way. Also, to be fully accurate, it is an attempt
shift the bookstore sideways in the reader's mind into a fantasy world
that mostly but not entirely parallels ours; as the introduction mentions,
this is not a strictly accurate day-by-day account of life at the store,
and stories have been altered and conflated in the telling.
Rare bookselling is a retail job but a rather strange one, with its own
conventions and unusual customers. Darkshire memorably divides rare book
collectors into Smaugs and Draculas: Smaugs assemble vast lairs of
precious items, Draculas have one very specific interest, and one's
success at selling a book depends on identifying which type of customer
one is dealing with. Like all good writing about retail jobs, half of the
fun is descriptions of the customers.
The Suited Gentlemen turn up annually, smartly dressed in matching
suits and asking to see any material we have on Ayn Rand. Faces
usually obscured by large dark glasses, they move without making a
sound, and only travel in pairs. Sometimes they will bark out a laugh
at nothing in particular, as if mimicking what they think humans do.
There are more facets than the typical retail job, though, since the
suppliers of the rare book trade (book runners, estate sales, and
collectors who have been sternly instructed by spouses to trim down their
collections) are as odd and varied as the buyers.
This sort of book rests entirely on the sense of humor of the author, and
I thought Darkshire's approach was perfect. He has the knack of poking
fun at himself as much as he pokes fun at anyone around him. This book
conveys an air of perpetual bafflement at stumbling into a job that suits
him as well as this one does, praise of the skills of his coworkers, and
gently self-deprecating descriptions of his own efforts. Combine that
with well-honed sentences, a flair for brief and memorable description,
and an accurate sense of how long a story should last, and one couldn't
ask for more from this style of book.
The book rest where the bible would be held (leaving arms free for
gesticulation) was carved into the shape of a huge wooden eagle. I m
given to understand this is the kind of eloquent and confusing
metaphor one expects in a place of worship, as the talons of the
divine descend from above in a flurry of wings and death, but it
seemed to alarm people to come face to face with the beaked fury of
God as they entered the bookshop.
I've barely scratched the surface of great quotes from this book. If you
like rare books, bookstores, or even just well-told absurd stories of
working a retail job, read this. It reminds me of True Porn Clerk Stories, except with much less off-putting
subject matter and even better writing. (Interestingly to me, it also
shares with those stories, albeit for different reasons, a more
complicated balance of power between the retail worker and the customer
than the typical retail establishment.) My one wish is that I would have
enjoyed more specific detail about the rare books themselves, since
Darkshire only rarely describes successful retail transactions. But
that's only a minor quibble.
This was a pure delight from cover to cover and exactly what I was hoping
for when I preordered it. Highly recommended.
Rating: 9 out of 10
Just some of the organisations that leaked data in 2022
It seems like just about every day there s another report of another company getting hacked and having its sensitive data (or, worse, the sensitive data of its customers) stolen.
Sometimes, people s most intimate information gets dumped for the world to see.
Other times it s just used for identity theft, extortion, and other crimes.
In the least worst case, the attacker gets cold feet, but people suffer stress and inconvenience from having to replace identity documents.
A great way to protect information from being leaked is to encrypt it.
We encrypt data while it s being sent over the Internet (with TLS), and we encrypt it when it s at rest (with disk or volume encryption).
Yet, everyone s data seems to still get stolen on a regular basis.
Why?
Because the data is kept online in an unencrypted form, sitting in the database while its being used.
This means that attackers can just connect to the database, or trick the application into dumping the database, and all the data is just lying there, waiting to be misused.
It s Not the Devs Fault, Though
You may be thinking that leaving an entire database full of sensitive data unencrypted seems like a terrible idea.
And you re right: it is a terrible idea.
But it s seemingly unavoidable.
The problem is that in order to do what a database does best (query, sort, and aggregate data), it needs to be able to know what the data is.
When you encrypt data, however, all the database sees is a locked box.
Not very useful for a database
The database can t tell what s in the locked box whether it s a number equal to 42, or a date that s less than 2023-01-01, or a string that contains the substring foo .
Every value is just an opaque blob of stuff , and the database is rendered completely useless.
Since modern applications usually rely pretty heavily on their database, it s essentially impossible to build an application if you ve turned your database into a glorified flat-file by encrypting everything in it.
Thus, it s hardly surprising that developers have to leave the data laying around unencrypted, for anyone to come along and take.
Introducing Enquo
I said before that having data unencrypted in a database is seemingly unavoidable.
That s because there are some innovative cryptographic techniques that can make it possible to query encrypted data.
Indeed
The purpose of the Enquo project is to provide a common set of cryptographic primitives that implement ENcrypted QUery Operations (ie Enquo ), and integrate those operations into databases, ORMs, and anywhere else that could benefit.
The end goal is to provide the ability to encrypt all the data stored in any database server, while still allowing the data to be queried and aggregated.
So far, the project consists of these components:
the enquo-core library, that implements queryable encrypted integers, dates, and text in Rust and Ruby;
a PostgreSQL extension, pg_enquo, that allows PostgreSQL to query encrypted data; and
a Rails ActiveRecord extension, ActiveEnquo, that augments ActiveRecord to do the encryption/decryption required.
Support for other languages and ORMs is designed to be as straightforward as possible, and integration with other databases is mostly dependent on their own extensibility.
The project s core tenets emphasise both uncompromising security, and a friendly developer experience.
Naturally, all Enquo code is open source, released under the MIT licence.
Would You Like To Know More?
Everyone who uses a database...
If all this sounds relevant to your interests:
If you use Ruby on Rails and PostgreSQL, you re halfway home already.
Follow the ActiveEnquo getting started tutorial and see how much of your data Enquo can already protect.
When you find data you want to encrypt but can t, tell me about it.
If you use Ruby and PostgreSQL with another ORM, such as Sequel, writing a plugin to support Enquo shouldn t be too difficult.
The ActiveEnquo code should give you a good start.
If you get stuck, get in touch.
If you use PostgreSQL with another programming language, tell me what language you use and we ll work together to get bindings for that library created.
If you use another database server, support is coming for your database of choice eventually, but at present there s no timeline on support.
On the off chance that you happen to be a hard-core database hacking expert, and would like to work on getting Enquo support in your preferred database server, I d love to talk to you.
co2mon.nz currently uses monitors based on Oliver Seiler s open source design which I am personally building. This post describes my exploration of how to achieve production of a CO2 monitor that could enable the growth of co2mon.nz.
I started out trying to use the EasyEDA/OSHWLab ecosystem thinking the tight integration with JLCPCB s assembly services would be a benefit, but the web interface was too clunky and limiting and I quickly got frustrated. KiCad proved to be a much more pleasant and capable tool for the job.
The reference design in the ESP32 datasheet (p28) and USB-C power supply examples from blnlabs were particularly helpful alongside the KiCad documentation and the example of the existing monitor in completing this step (click the image to enlarge).
Taking all of these factors into account I ended up with a square PCB containing a cutout in the top right so that the ESP32 antenna can sit within the overall square outline while still meeting its design requirements. The SCD40 and BME680 sit in the top left corner, near the edges for good airflow and far away from the SHT30 temperature sensor in the bottom left corner. The LEDs I placed in a horizontal row across the center of the board, the LCD in the bottom right, a push button on the right-hand side and the USB-C socket in the center at the bottom.
Once the components are placed, the next big task is to route the traces (aka wires) between the components on the board such that all the required electrical connections are made without any unintended connections (aka shorts) being created. This is a fun constraint solving/optimisation challenge and takes on an almost artistic aspect with other PCB designers often having strong opinions on which layout is best. The majority of the traces and routing for this board were able to be placed on the top layer of the PCB, but I also made use of the back layer for a few traces to help avoid conflicts and deal with places where different traces needed to cross each other. It s easy to see how this step would be much more challenging and time consuming on a larger and more complex PCB design.
The final touches were to add some debugging breakouts for the serial and JTAG ports on the ESP32-S3 and a logo and various other helpful text on the silkscreen layer that will be printed on the PCB so it looks nice.
The final surprise in the assembly process was the concept of edge rails, additional PCB material that is needed on either side of the board to help with feeding it through the assembly machine in the correct position. These can be added automatically by JLCPCB and have to be snapped off after the completed boards are received. I hadn t heard about these before and I was a little worried that they d interfere or get in the way of either the antenna cut-out at the top of the board, or the switch on the right hand side as it overhangs the edge so it can sit flush with the case.
In the end there was no issue with the edge rails. The switch was placed hanging over them without issue and snapping them off once the boards arrived was a trivial 30s job using a vice to hold the edge rail and then gently tipping the board over until it snapped off - the interface between the board and the rails while solid looking has obviously been scored or perforated in some way during the production process so the edge breaks cleanly and smoothly. Magic!
The process was amazingly quick with the completed PCBs (picture above) arriving within 7 days of the order being placed and looking amazing.
As a result I ended up completely flipping the design such that the front panel is a single piece of plastic that also encompasses the walls of the case and contains appropriate mounting stakes for both the screen and the main PCB.
Getting to this design hugely simplified the assembly process. Starting with an empty case lying face down on a bench, the LCD screen is pushed onto the mounting poles and sits flush with the cover of the case - easily achieved without the main PCB yet in place.
Next, the main PCB is gently lowered into the case facing downwards and sits on the mounting pole in each corner with the pins for the LCD just protruding through the appropriate holes in the PCB ready to be quickly soldered into place (this took significant iteration and tuning of dimensions/positioning to achieve!).
Finally, a back panel can be attached which holds the PCB in place and uses cantilever snap joints to click on to the rest of the case.
Overall the design is a huge improvement over the previous case which required screws and spacers to position the PCB and cover relative to the rest of the case, with the spacers and screws being particularly fiddly to work with.
The major concern I had with the new design was that the mount to attach the monitor to the wall has moved from being attached to the main case and components directly to needing to be on the removable back panel - if the clips holding this panel to the case fail the core part of the monitor will fall off the wall which would not be good. To guard against this I ve doubled the size and number of clips at the top of the case (which bears the weight) and the result seems very robust in my testing. To completely assemble a monitor, including the soldering step takes me about 2-3 minutes individually, and would be even quicker if working in batches.
I tried a variety of filament colours, but settled on a transparent filament which once combined in the necessary layers to form the case is not actually transparent like perspex is, but provides a nice translucent medium which achieves the goal of having the light colour visible without exposing all of the circuit board detail. There s room for future improvement in the positioning of the LEDs on the circuit board to provide a more even distribution of light across the case but overall I really like the way the completed monitor ends up looking.
The goal of having a CO2 monitor which I can outsource the vast majority of production of is as close to being met as I think is possible without undertaking the final proof of placing a large order. I ve satisfied myself that each step is feasible and that the final assembly process is quick, easy and well below the level of effort and time it was taking me to produce the original monitors.
Cost wise it s also a huge win, primarily in terms of the time taken, but also in the raw components - currently the five prototypes I ordered and built are on par with the component cost of the original CO2 monitor, but this will drop further with larger orders due to price breaks and amortisation of the setup and shipping expenses across more monitors.
This project has also given me a much better appreciation for how much I m only just scratching the surface of the potential complexities and challenges in producing a hardware product of this type.
I m reasonably confident I could successfully produce a few hundred and maybe even a few thousand monitors using this approach, but it s also clear that getting beyond that point is and would be a whole further level of effort and learning.
Hardware is hard work. That s not news to anyone, including me, but there is something to be said for experiencing the process first hand to make the reality of what s required real.
The PCB and case designs are both shared and can be found at https://github.com/co2monnz/co2monitor-pcb and https://github.com/co2monnz/cad, feedback and suggestions welcome!
Taking all of these factors into account I ended up with a square PCB containing a cutout in the top right so that the ESP32 antenna can sit within the overall square outline while still meeting its design requirements. The SCD40 and BME680 sit in the top left corner, near the edges for good airflow and far away from the SHT30 temperature sensor in the bottom left corner. The LEDs I placed in a horizontal row across the center of the board, the LCD in the bottom right, a push button on the right-hand side and the USB-C socket in the center at the bottom.
Once the components are placed, the next big task is to route the traces (aka wires) between the components on the board such that all the required electrical connections are made without any unintended connections (aka shorts) being created. This is a fun constraint solving/optimisation challenge and takes on an almost artistic aspect with other PCB designers often having strong opinions on which layout is best. The majority of the traces and routing for this board were able to be placed on the top layer of the PCB, but I also made use of the back layer for a few traces to help avoid conflicts and deal with places where different traces needed to cross each other. It s easy to see how this step would be much more challenging and time consuming on a larger and more complex PCB design.
The final touches were to add some debugging breakouts for the serial and JTAG ports on the ESP32-S3 and a logo and various other helpful text on the silkscreen layer that will be printed on the PCB so it looks nice.
I tried a variety of filament colours, but settled on a transparent filament which once combined in the necessary layers to form the case is not actually transparent like perspex is, but provides a nice translucent medium which achieves the goal of having the light colour visible without exposing all of the circuit board detail. There s room for future improvement in the positioning of the LEDs on the circuit board to provide a more even distribution of light across the case but overall I really like the way the completed monitor ends up looking.
I've moved to having containers be first-class citizens on my home network, so
any local machine (laptop, phone,tablet) can communicate directly with them all,
but they're not (by default) exposed to the wider Internet. Here's why, and how.
After 
Just a few days back we came to know about the horrific Train Crash that happened in Odisha (Orissa). There are some things that are known and somethings that can be inferred by observance. Sadly, it seems the incident is going to be covered up 
. Some of the facts that have not been contested in the public domain are that there were three lines. One loop line on which the Goods Train was standing and there was an up and a down line. So three lines were there. Apparently, the signalling system and the inter-locking system had issues as highlighted by an official about a month 
The following contributors got their Debian Developer accounts in the last two months:
I wrote the 
Wrong sort of shim, but canned language bindings would be handy
This is what I imagine it looks like inside these libraries
Just some of the organisations that leaked data in 2022
Not very useful for a database
Indeed
Everyone who uses a database...
